3,151 karma · joined October 7, 2009
phzbox at gmail @phzbox
Personally, I don't like the "write client-side resolvers mimicking the server resolvers" approach. I'd much rather have a database that is synched with the server and listens for new changes. Once you have your "offline-synched-db", you get offline, optimistic-UI & real-time for free.
More specifically, for DOTA, they could track the progress and make sure there wasn't important regressions.. but this seems so general, how can they make sure it makes everyone' use-cases better?
Often people refresh the browser or re-run their CLI program until their feature is finished.
But if you think about it, every "refresh to check if it works" is just a manual test. TDD is just making that manual test automated.
1. Write that test (that you'd anyway have to run manually)
2. Write code until test pass
3. Repeat 1 until done.
Code that aren't designed with a test-first mentality is often really hard to test and require complicated tools or need to mock the whole world.
For the examples you've mentioned:
- I'd unit tests the db service layer (I.e. functions to fetch from db, make sure schema is valid)
- I'd unit tests the various API queries (I.e. filtering, pagination, auth)
- At the controller level, I'd just unit test the business logic and data fetching part.
- Then I'd add a few E2E tests for the UI and user interactivity.
But if you think about it, any of these tests would have had to be run manually anyway. I.e. You'd probably have queried your API with various options and refreshed the page(s) a few time to make sure data was fetched correctly.
Also:
1. cut features and enjoy saying no.
2. set deadlines and ship (if not enough time, see 1 above)
3. don't skip tests; makes refactoring/rewriting a breeze