Because timestamps are useful: Structure 5:14 - Too Big To Fail 8:45 - Off-Script 11:15 - Hard to Skim 13:55 - Too Magic / Not Magic Enough 15:49 - Accidentally Creative Isolation 18:17 - Unfocused Test Suites 20:53 - Too Realistic 23:15 - Redundant Coverage 25:46 - Careless Mocking 28:06 - App Framework Test Feedback 30:01 - Bad Error Messages 32:05 - Slow Feedback Loops 35:06 - Painful Data 36:57 - Superlinear Build Slowdown 39:58 - False Negatives
@BroileR20078 ай бұрын
This is a great talk. I have one objection. Although I agree with most of what Justin said, I'd hate to see the like of his examples in a real project. It looks nice when there are 5 lines of test code, but easily gets out of hand as the test file grows. Naming the object under test a "subject" reduces the descriptiveness of a test, imagine scrolling 500 lines up to see what "subject" means, or when there are 10 "subject" definitions in a file, sprinkled all around nested contexts, and you try to find which one is actual for the given test. Or similarly, when all your tests are one-liners and to understand their setups and expected values you have to go hunting around the whole test file. I've worked on a project like this and it was intolerable. So please, people, don't follow these examples dogmatically, use your judgement.
@TheIronSavior8 жыл бұрын
Audio is really screwy at 35 min
@mvargasmoran5 жыл бұрын
YES! I wasn't alone (even though I super late to this party)