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.
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 :)
Thanks for re-recording and sharing, I really appreciate it.
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.
That's good food for thought! Thank you for re-recording and sharing
Thanks for sharing, great speech
Awesome presentation, your Script tool seems very useful. Thanks Russ!
These were great tips. Thanks :)
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.
Great stuff! Though one thing I've noticed, syntax on 16:42 is missing "range"
also at 17:24 it should be t.Errorf
I like to write my tests with random data using Gofakeit
great
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 :)
4:16 "If they want to make a change, ... they just *mail* the change."
What do you mean by "mail" the change? Why are you mailing changes?
Many code review systems send notifications by email, and so the act of sending someone a change for review is often referred to in this way.
TIp #3 台灣有一句名言是「我吃過的鹽比你吃過的飯還多」這很適合用在這裡。年紀比較大、覆蓋率比較高，並不代表智慧或思考比較多。因此他是一句邏輯謬誤。