I was thinking of cloning the code, getting rid of all the code except the specs and then writing the the code on my own and comparing my code with the upcase code. And then ask here about the stuff.
I would like to see a lot more discussion about the Upcase code. I like to look at how certain things are tested. One thing Iāve been looking for are good examples of Inversion of Control or Dependency Injection in real projects. I know about the payload gem, but Iāve started using a builders directory until I need a separate IoC container
@aaronmcadam, you brought up a good point: discussion of the Upcase code and its use as the base for Weekly Iteration episodes is definitely something Iād like to see (more).
I think that a discussion on āhow to test examples of IoC or DIā is not something that can be done in a simple manner. You write your tests and see where they take you, it very much is an āorganicā process: Red, Green, Refactor. At the latter point, you might find youād want to refactor in order to make your code more SOLID and a refactoring wouldnāt (shouldnāt?) change your tests.
This is a very interesting discussion to have. I donāt believe in deciding on design or writing tests with āintent to implementā a design pattern/principle. All of that should emerge from the code, in my opinion.
That being said, nothing like picking up a tool and using it to expand your understanding: just kicking up an app with the intention of exploring is the way to go The Upcase code has been growing and evolving for some time and that is where I found most of its value - reading through the history, the code reviews and discussions that led to a decision.
I think it would help to see how to test every letter of SOLID. Itās ok showing small, contrived examples, but without demonstrating how to test it, it can be difficult to know what the best trade-offs are.