So we had our second meeting on Monday, this is a brief summary of what was discussed.
- Details on how Assert works, the fact that the methods are static.
- Testing Exceptions: This led to a very interesting discussion on how most frameworks handle this.
We talked about the Assert.Throws from NUnit and how its really nice to be able to do something like this
Assert.Throws<NullReferenceException>(user.WillThrowAnnNullExecption);
or even something like this
var e= Assert.Throws<NullReferenceException>(e.WillThrowANullExecption);
Assert.AreEqual(”Object reference not set to an instance of an object.”, e.Message);
Ok the message in this case is not very valuable but you can see how you can get very specific, the fact that the exception is returned is really valuable. By the way I just tried this and it is true
- Test failures could lead us to write more tests. We discussed the ways we handle this: some people use todo lists ( as per TDD by Example by Kent Beck), some people write test that are not implemented, some people use a combination of both.
- Liked the fact that it mentioned that tests should be independent of each other at this early stage of the book.
-Test Initialization Setup and TearDown as well as FixtureSetUp and FixtureTearDown and how they work.
I thought this was a good place to mention this as it took me a while to know that they existed, also mentions the advantage of having one place to call the constructor of the class under test.
David showed us something a bit smarter, he uses a factory that creates a valid object with the required properties set up using lambdas. This is good because you can see what is that you need in your test and its in one line and still have all the constructor usage in one place.
- Ignore attribute. After discussing, this seemed like a bad idea unless you were very disciplined.
- Category. The consensus was that we really didn’t think it was a great idea in general to use this feature, because you might not run all tests. Might be a “test smell”, good to know is there tho.
- Finally the book mentions Indirectly testing state, I think, as a way to give way to the next chapter.
Other things:
We keep mentioning these three books at all times ( no specific order)
xUnit : Test Patterns
TDD by Example
Working Effectively with Legacy Code
We were also talking about mbUnit versions and actually today i saw this blog post about mbUnit being in version 3.1.
Jacob mentioned that the existence of a test support for Silverlight, which is great, however he also mentioned that is possible to mark something as a bug so the test will pass, this didn’t seem so good.
Did I forget something?