← Back to Upcase

Best way to learn from the upcase code?


(Charlieanna ) #1

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.

Is this a viable option to learn from the repo?

Thanks


(Aaron Mc Adam) #2

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


(Pedro Moreira) #3

@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 :slight_smile: 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.


(Aaron Mc Adam) #4

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.


(Ben Orenstein) #5

We can definitely do that.