While implementing the Go version (#7), I came across a few shortcomings of the existing implementations (CS/Java)
Existing objects are barely tested
Domain objects are clumsy to set up (although a little easier in Go, with literal initializers) - see also #8
Implementing the printer, I realized that this printer does not generate output that matches that of the feature files.
Furthermore, working on the CashSpecsDriver, this one already foreshadows the API of the CashRegister interface. Would there ever be a point in thinkint about a different API?
I suggest to define precise high-level requirements on the existing code; Whether it should be "as polished" as possible or barely working, how the output should be across languages and so forth - because this affects (even muddles) the primary intent of the kata.
Or remove the "TODO" marker and simply define the goals per session (clean up the code, make missing unit tests, ...)
While implementing the Go version (#7), I came across a few shortcomings of the existing implementations (CS/Java)
I suggest to define precise high-level requirements on the existing code; Whether it should be "as polished" as possible or barely working, how the output should be across languages and so forth - because this affects (even muddles) the primary intent of the kata. Or remove the "TODO" marker and simply define the goals per session (clean up the code, make missing unit tests, ...)