05:02 Tip #01: Make it easy to add new test cases. 06:05 Tip #02: Use test coverage to find untested code. 07:26 Tip #03: Coverage is no substitute for thought. 09:21 Tip #04: Write exhaustive tests. 11:39 Tip #05: Separate test cases from test logic. 12:01 Tip #06: Look for special cases. 13:30 Tip #07: If you didn’t add a test, you didn’t fix the bug. 15:26 Tip #08: Not everything fits in a table. 17:28 Tip #09: Test cases can be in testdata files. 17:57 Tip #10: Compare against other implementations. 19:46 Tip #11: Make test failures readable. 20:57 Tip #12: If the answer can change, write code to update them. 21:41 Tip #13: Use txtar for multi-file test cases. 24:56 Tip #14: Annotate existing formats to create testing mini-languages. 26:38 Tip #15: Write parsers and printers to simplify tests. 28:36 Tip #16: Code quality is limited by test quality. 30:14 Tip #17: Scripts make good tests. 30:53 Tip #18: Try rsc.io/script for your own script-based test cases. 32:00 Tip #19: Improve your tests over time. 33:14 Tip #20: Aim for continuous deployment.
I kinda like *and* dislike the advise for the DSL. Sometimes an internal DSL is really nicer b/c of the IDE integration and completion. Then again, maybe a DSL as shown should be so KISS that its usage should be obvious.
Are there any good resources or examples for what it takes to test a web app from top to bottom? I can conceptualize testing individual methods with no problem but when I start to think about layering an app my head starts to spin. All but the most trivial app will have layers, services, interfaces, etc. Testing idempotent functions is simple but testing the seams between application layers is where my understanding of testing seems to run out.
Nice presentation, thanks for that. I would add that following TDD is able to solve many of the issues you raised but I understand that it's not everyone cup of tea :)
