very informative, I for one have been guilty of many of these errors, and hopefully I have been made aware of them now.
Thanks again for a great screencast
Thanks Roy. Great tips.
Thanks for the screencast. Very cool. Just a thought on what you call "magic string". Instead of specifying the simplest value (you used "a" everywhere), I use something like "AnythingWillWorkHere". Similarly, when a value is not used (in a mock or stub, for example) I will use "Ignored". Just a thought.
Thanks Roy. These videos are very interesting and full of helpful tips!
It would be great to see a review of an application with really _good_ tests.
Dig the comments on the use of Ignore, though I would have been a little more brutal. I personally wish it had never been introduced. Either fix the broken implementation if the test is correct, or delete the broken test. If your actually going the TDD route, then the test should continue to fail until the development of the feature/component is complete.
As to the unneeded asserts of not null, I still can't find the issue here. Roy clearly believes that a single assert per test is THE way to go. My problem is I still fail to see his reasoning here. He has stated in all three videos that this is a bad idea since all the asserts after the first failure will not execute. OK, this is true; however, isn't the goal to make it all pass and if so why does it matter? Even if the arrange/act of the test is only 1 or 2 lines, I would be livid with a developer that copy/pasted those lines into 20+ functions just so he have a single assert per test. Doesn't that make it unmaintainable? Doesn't spreading this across 20+ methods make it hard to read? Just my 2 cents.
Show us the surf board!!! :)
Roy, I would be very interested to see your comments on what "csharptest" had to say about single-assert-per-test. Could a refactoring into [Setup] resolve his concerns? What do you think?