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?