I hope you all had a great time at Code Camp and a safe journey back home.
This blog post is to provide you with some additional references on the presentation Real World Unit Testing & Future. I have also included some answers to the questions which some of you have had after the presentation. At the end of this post, there is a link and you can download my presentation slides.
Download TestLint http://site.typemock.com/test-lint/
Links to Roy Osherove’s Test Reviews.
Unity : http://weblogs.asp.net/rosherove/archive/2009/03/23/test-review-3-unity.aspx
ASP.NET MVC : http://weblogs.asp.net/rosherove/archive/2009/03/21/test-review-2-asp-net-mvc-unit-tests.aspx
Question on multiple Asserts in a Unit Test?
Post presentation questions interested me that some of you have different opinions on having multiple asserts within a Unit Test. The point I wanted to make was, as a general rule, it is best to have one assert per Unit Test. Having said that, there may be instances where you would like to test logically related things within the same Unit Test. Which means “Multiple aspects of the same object”. If one aspect fails then we would consider as the Unit Test is fail.
[TestMethod]
public void TraceOutput_SimpleStringWithCommaDelimitted_AnalyseTraceData()
{
TraceAnaliser traceAnaliser = new TraceAnaliser();
AppTraceOutput traceOutput = traceAnaliser.AnalyseTraceData("Europe, Africa, 10:00, Australia, Simon");
//Different aspects of the same object being tested.
Assert.AreEqual(traceOutput.ReadLine(1)[0], "Europe");
Assert.AreEqual(traceOutput.ReadLine(1)[1], "Africa");
Assert.AreEqual(traceOutput.ReadLine(1)[2], "10.00");
Assert.IsTrue(traceOutput.LineCount == 1);
}
If you want to make the above test more maintainable you would also consider comparing the objects. For example…
Assert.AreEqual(traceOutput, expected);
Having multiple asserts in Unit Tests raise maintainability issues. If the first assert fails, then the subsequent asserts will never get executed. We would never know those subsequent asserts were succeeded or not. Since it is a partial picture, sometimes it is very hard to isolate the problem why the Unit Test is failing. If the tests are separated and solid they are easier to read and easier to maintain.
Also I came across with another tool (NUnit Addin for Running one assert per test ) which I did not include in my talk, but please feel free to have a look at this.
The difference between the Code Contracts and Unit Tests.
There was a question on Code Contracts and Pex. Code Contracts allows you to perform powerful assertions within your production code. It encapsulates the intention of your design using contracts, so the compiler tools using Static Analysis, Runtime Analysiscan be used to discover those intentions (E.g Pre Conditions and Post Conditions). Unit Test, verifies a piece of logic/behaviour within a method while allowing you to improve the design of the production code. One cannot replace each other as they both have different purposes.
Download Code Contracts and Pex
Code Contracts – http://msdn.microsoft.com/en-us/devlabs/dd491992.aspx
Pex – http://research.microsoft.com/en-us/projects/pex/
Where can I get more information on Code Contracts and Pex?
Here is a video from PDC 2010 which explains some useful information using Pex and Code Contracts. http://channel9.msdn.com/Blogs/martinesmann/Code-Contracts-and-Pex-Power-Charge-Your-Assertions-and-Unit-Tests
Download Sinon, JSTestDriver and QUnit
a. Sinon – http://cjohansen.no/en/javascript/javascript_test_spies_stubs_and_mocks
b. JSTestDriver – http://code.google.com/p/js-test-driver/
C. QUnit – http://docs.jquery.com/Qunit
d. QUnit to JSTestDriver adaptor – http://code.google.com/p/js-test-driver/wiki/QUnitAdapter
(Note : I will soon write a separate blog post on how to automate this within VS 2010)
Powerpoint slides. Real world Unit Testing & Future.pptx (971.90 kb)
Code Camp 2010 – Real world unit testing from David Burela on Vimeo.
Raj Aththanayake 