I think it might be worth adding more detail to the description about the number of traffic lights that can be controlled.
I assume the intent is that the Traffic Light Controller can handle any number of traffic lights, however, in part 2 we're only interested in dealing with up to 2 traffic lights. In later parts the controller will need to deal with more lights.

I think it's up to the programmer whether they deal with only a max of 2 lights or any number of lights as long as the tests pass. However, knowing the above might make it easier to understand why you only mention two lights in the rest of your description.

p.s. looking forward to the next part!

@dibley1973

I saw the feedback given to @Kalanndok for the ITrafficLight interface.

My feedback wasn't seeking to suggest you change that interface as you clearly explained why you've designed it. I assume you've misinterpreted my statement, "Also it seems a little odd to have a State that say's which lights are on/off followed by properties on the traffic light which also say which lights are on and off.". This statement was merely a precursor to setting up the idea of having the Signal enum with the suggested values, which allows for clearer decoupling of the following concepts:

• Message the traffic light should convey (i.e. the Signal) to the driver ... and ...
• The mechanism used to give the message (i.e. ITrafficLight).

Ultimately I'm only really suggesting you tweak the available values of the enum... and I'm of course more than happy to wait until part 3!!!

Hi, thanks for this Kata - not too taxing, which is nice once in a while!

A couple of points on the State that is set on the lights.

In the description of the problem it describes State as having x "options". It's unclear from the description what State is, it would be clearer if it said that State is an enum with the following values.

Also it seems a little odd to have a State that say's which lights are on/off followed by properties on the traffic light which also say which lights are on and off. Might it be better to have the following states (or similar) and let the traffic light decide which lights must be on and off accordingly:

• Standby
• Stop
• Go
• PrepareToGo
• PrepareToStop

State might also be better referred to as Signal

The Kata description is far more complex than the problem at hand. I nearly skipped the Kata it sounded so confusing. In the end it is a simple problem, broadly summed up by the last paragraph. The Kata would benefit from using the virtual keyword on the underlying TakeTheGarbageOut method. Also perhaps it would be simpler to have the son take out the garbage differently than the rest of his family - it is problematic to model the problem of the son taking out garbage like his uncle, whilst adhering to good practice, given the contraints of the kata.

As this Kata appears to be for beginners...
Consider using descriptive variable names, e.g.

Bath(string text, string bathTub)

Also it might be worth describing that the bath tub's sides are defined by the | pipe symbols and it will always have two sides.

The test numbers are smaller than the max of a signed 32bit integer. However, with each rotation through the queue you take a name out and then put it back on twice. As such the queue is growing exponentially in size and eventually the compiler is throwing an error when the queue is too large to fit any more entries in it.

I'm only commenting as my original solution was similar to yours and I hit the same problem!

It's not because the tests stop after some time... I think it's because the Queue is growing expodentially in size and exceeds the Int32 limit.