oop-design-workshop.md

OOP Design workshop

Part 1

• Initial step: Plan the user story (goals, acceptance tests).
• Getting familiar with the CEP SOAP API.
• Test as a documentation for external API usage.
  • Introduce spec/use_cases.
• byebug as a tool for API learning & discovering.
• Don't be bothered about duplication while enough use cases are not fully covered yet.
• Should I use VCR right now? Maybe yes, just for sake of convenience, since setting up response stubs manually can be error-prone (but we can keep it touching the network from now).
  • Most important and valuable thing: keeping real interaction with external services with a good level of integration.
• Specs description are naturally used as the git commit messages.
• First red green cycle is done. Time to the first refactoring.
• Reinforce the importance of 4 phases of test.
• Reinforce the importance of having minimal code that gets things done (don’t bother about questions like dotenv usage, public api, namespaces, lib vs model, since we’re still maturing knowledge).
  • No code is usually better than good code.

Part 2

• First step on coding the feature: dig from the outside-in.
• TDD outside the test suite (or, leveraging TDD mindset in the browser).
• Realize the proper moment to give the first level of acceptance test (i.e., from the browser to Capybara).
• Realize the proper way to break the commit in meaningful parts.
• All the user scenarios work now, but resulting code is not good (refactor with CepConsultation).
• Introduce test pyramid (refactoring tests) (http://www.mountaingoatsoftware.com/blog/the-forgotten-layer-of-the-test-automation-pyramid).
• Introduce “Shallow Depth of Tests” (http://fabiopereira.me/blog/2012/03/18/introducing-depth-of-test-dot/).

Part 3

• Integrating the CEP API with the CepConsultation service
  • Note that specs & behavior do not change, since, at this time, we have a solid interface established between architecture ports).
• Working software is done. We have not open the browser since first step on part 2, and everything was conceived from TDD cycle. Code can be shipped to production.
• Complexity is isolated (CepConsultation), but code is not well factored.
• Primary code smells:
  • Test suite is slow
  • CepConsultation has many responsibilities (CEP api client, CEP response logic, presentation logic).
  • Boundaries are “violated”.
• Refactoring techniques: extract method.
• Listen to your code: FeatureEnvy.

---

Incidental divagations

• DPY: Don’t precipitate yourself.
• The correlation between TDD and automated tests.
• Some thoughts about git messages:
  • Git messages exposes how you think about your software.
  • If you messages talk about your system and not about your framework, then you’re good.
  • Therefore, do not tell the obvious, let your code do.
  • Talk about your intentions, not the solution.

Incidental references

• Interface segregation principle.
• Hexagonal architecture.
  • http://fideloper.com/hexagonal-architecture
• Functional core, imperative shell.