Tests are woefully inadequate, they don't even check if the methods would call other relevant methods (e.g unsubscribing a runway from a ATCClient should unsubscribe it from the runway).

No random tests.

This is not really a factory pattern, what the author wants is a class whose sole purpose is doing a table look-up, which is an OOP misuse if anything. The other requirements are either duplicates at this point (reverse a string), or they're plain worthless (wrap a method in a function, add an attribute to a class).

Also, there're no random tests.

Task is poorly explained:

• Do we use B or iB? One of them has multiplier of 1024 and the other is 1000
• The output should be a string with following units: B, KB, MB, GB, TB, PB What do these units mean? How do they relate to each other?
• It's not mentioned that input is always an integer
• It's not mentioned that output does not need to trim trailing zeroes (e.g 5.50 MB and not 5.5 MB)
• Actual task is buried under lots of unrelated things: You could've just told us to return a function in the filter body that does the task

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.

Typescript translation kumited! Please Accept :D