OOP Design workshop
- 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.
- 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
- 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/).
- Integrating the CEP API with the
- 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
CepConsultationhas many responsibilities (CEP api client, CEP response logic, presentation logic).
- Boundaries are “violated”.
- Refactoring techniques: extract method.
- Listen to your code: FeatureEnvy.
- 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.
- Interface segregation principle.
- Hexagonal architecture.
- Functional core, imperative shell.