fast-tests-drive-toward-clean-architecture

blog-post-ruby-derailed-fast-tests the guy mentions the repository pattern

From the Hydra guy also seems to not like mocking much talk-grease-your-suite and talks about testing-concept-fast-contexts

DHH: "the simplicity of the system is downgraded in order to ease the job of mocking. Terrible idea."

testing-concept-clean-architecture

11:15 - for speed, using hexagonal architecture so you can plug in very fast simulators (#)

What happens when you care only about fast tests?

• You choose Sinatra
• You ensure that an in-memory datastore can be a direct replacement for the actual datastore, much like the guys in this post did: blog-post-clean-architecture-2
• You push towards a clean architecture? Possibly
• You use the latest Ruby (see http://www.isrubyfastyet.com/)
• You don't wrap your actual test runs in rake, but rather run them in a specialized runner file
• You use minitest instead of rspec (always true?)
• You can add new functionality quickly (and in very small steps)
  • DHH talked about how having a limited amount of time to work on rails each day was actually helpful in building rails
• less need for mocks for their speed alone
  • in talk-tdd-where-did-it-all-go-wrong Ian says that Didn't mean for unit tests to be isolated tests that are mocked.
  • the Hydra guy also seems to not like mocking much talk-grease-your-suite
    • he also talks about "empty database" tests (where you factory everything in)
  • Ryan Davis also doesn't like mocking much talk-minitest-insights
• You are able to run experiments that speed things up even more quickly, since you can run the experiments quickly

Advantages of fast tests

• Flow
• CI server vs. fast tests, from near the beginning of: talk-grease-your-suite

References

• blog-post-clean-architecture-2
• blog-post-slow-tests-are-the-symptom-not-the-cause
• project-obvious

Referring Pages