Draft
Design Patterns: Observer Pattern for the runway status at an airport
10lyckade
Loading description...
Design Patterns
Algorithms
This comment has been reported as {{ abuseKindText }}.
Show
This comment has been hidden. You can view it now .
This comment can not be viewed.
- |
- Reply
- Edit
- View Solution
- Expand 1 Reply Expand {{ comments?.length }} replies
- Collapse
- Spoiler
- Remove
- Remove comment & replies
- Report
{{ fetchSolutionsError }}
-
-
Your rendered github-flavored markdown will appear here.
-
Label this discussion...
-
No Label
Keep the comment unlabeled if none of the below applies.
-
Issue
Use the issue label when reporting problems with the kata.
Be sure to explain the problem clearly and include the steps to reproduce. -
Suggestion
Use the suggestion label if you have feedback on how this kata can be improved.
-
Question
Use the question label if you have questions and/or need help solving the kata.
Don't forget to mention the language you're using, and mark as having spoiler if you include your solution.
-
No Label
- Cancel
Commenting is not allowed on this discussion
You cannot view this solution
There is no solution to show
Please sign in or sign up to leave a comment.
Tests are woefully inadequate, they don't even check if the methods would call other relevant methods (e.g unsubscribing a runway from a
ATCClientshould unsubscribe it from the runway).No random tests.
Also, consider specifying in the text of description (and not just in test cases) what behaviour do you expect and what fields are required for each class. Currently, you do not specify explicitly what happens to .runwayStatus in client objects after they unsubscribe. Also, judging from your own code, clients behave differently: GroundServiceClient just changes .runwayStatus to empty string, while ATCClient deletes the whole runway - so trying to access runwayStatus will probably cause an exception. This is not intuitive, you should specify this somewhere.
This is a very nice kata! I was looking for something that helps exploring design patterns.
However, I believe test cases could be more detailed. Currently, example test cases are just the same as final test cases. I think it is a good idea to add some more, checking different things.