Slow tests with nunit 2.4 and nhibernate
I noticed that when I used nunit 2.4 test runner it is really slower than 2.2. The reason is that in 2.4 the nunit test runner will use log4net as default logger, and if you do not disable logging, you will see in log tab an enormous amount of text.
The reason is that nunit used default log level of “DEBUG”, and this in turn means that nhibernate will run with full logging enabled, and this is a really waste of time because nhibernate really log everything with DEBUG level. The solution was (until version 2.6) to disable the log tab of the test runner, but in subsequent version this behavior seems to be corrected. So upgrade to the latest version if you experience slow tests with nhibernate and nunit 2.4.x where X < 8 :D.
alk.
Mix Linq2XML and XPath, take the best from both
I must admit that LINQ 2 Xml impressed me very much, I’m actually using it to modify docx documents with the OpenXml sdk. While Linq 2 xml is really useful to makes query and find nodes in xml, I found it rather clumsy in my unit test code. Ex.
I’m writing a test that must verify if my table class correctly generate the header. In openXml format the header is simply created with a w:tblHeader node in the first w:tr (the first row) element of a table. The unit test have this structure
[Test] public void SetHeaderTest() { OpenXmlTable table = new OpenXmlTable(); table.NextCell("FirstCell") .NextCell("SecondCell") .NewRow() .NextCell("Third") .NextCell("Fourth") .SetHeader(1); XElement e = table.GenerateXmlData(null, GetSubToken()); //now assert that the xml is good }
I left the assertion part blank, because now I have to find a way to test that my table class correctly created the w:tblHeader node in the right place. with Linq2Xml you can select with descendants the node called w:tblHeader, but then you should check that it was positioned in the right place. Moreover an assertion should be crystal clear, and I prefer to use XPath because for these kind of selection I found it to be clearer.
Linq2Xml classes permits you to issue an XPath query against an XElement, and this is really the stuff I need, but when you deal with namespace, you should pay a lot of attenction to select the correct node. Since the root node in my situation has namespace declaration I can simply issue this assertion
Assert.That(e.XPathSelectElement( @"./w:tbl/w:tr[1]/w:trPr/w:tblHeader", e.CreateNavigator()), Is.Not.Null);
I’m used with XPath but this is a very simple expression, @”./w:tbl/w:tr[1]/w:trPr/w:tblHeader” you can read it it means, find the elment tblHeader son of trPr son of the first tr element son of the tbl element. This assertion is simple and verify that the first row in the table set as header. Moreover you should tell to XPath engine the definition of the namespace w, but since it is defined in my original XElement it is enough to pass the node navigator as the second parameter.
The ability to mix LINQ2XML code with XPAth code permits me to take the best from both world and I appreciate very much that XDocument and XElement natively supports query with XPath.
alk.
Favor small and frequent checkin over big ones.
This is a rule that I try to adopt since long time in the past, and few days ago Jeff Atwood enforces this concept in his blog. I completely agree with him, code should be checked in often, especially when you have continuous integration server. Checking in often reduce the risk of conflicts, makes tests run often (you should have setup your continuous server to run all tests for each checkin) and makes integration simplier. Benefit of frequent checkins are
- Other developers are immediately aware of yours modifications, you can have immediate feedbacks
- As I said tests are run often with code of other developers (think to the scenario where you finally merge your changes and with pain you verify that a lot of tests are now failing)
- if some code path is gone wrong, you can simply revert local changes and begin again from a good starting point.
I usually follow the pattern of “implement something new, run all tests, update local files again to check for conflicts, resolve any conflict, then commit with a comment telling the reason of the commit”. When I correct bugs, I correct a single bug, then run the tests, update, resolve conflicts and commit with a comment that tells the number of the bug that was corrected.
But sometimes programmers are going into big changes of the code, they begin to change a lot of files, and tends not to checkin until the work is finished, this is wrong. One possible solution is creating a branch, you can checkin often without the risk to break the build, you can checkin incomplete code (the only condition is that it compiles), you can watch out the change on the corresponding files on the trunk, so you can merge often from the trunk to your branch, and finally when you are done with the change you can merge last stuff and move into the trunk the new code. The greatest advantage of this approach is that the other programmers are continuously aware of your work. Suppose programmer A find a bug in class Foo, he can correct the bug on the trunk and immediately make the same correction on all active branches.
Another approach can be taken when you use IoC in your application. Suppose that I need to radically refactor component Foo that implements the interface IFoo. I simply begin to create another component called Foo2 or FooBetter or whathever you like, I develop it, test it, and when I think that it is finished I simply change configuration file to use the new component. When everyone says that the new Foo is ok, then I can delete the old Foo. The good thing is that I can run all test suites regarding the old Foo class against the new one, until all the tests passes.
Both these approaches are better than keeping local changes for too long and doing a final big chekin. Remember the rule, favor small and frequent checkins over big and infrequent ones.
alk.
Tags: SCS Code CheckIn Continuos Integration
I love fluent interfaces.
I’m developing a little library that basically does these steps
1) open a docx file
2) Find a particular bookmark in the file
3)Add some content at bookmark position
4) Save the updated file.
This is a typical call
I like very much this kind of syntax, since we chain every method we always have intellisense that suggest us what to call, if you read the code you can easily check that we add two simple cell with text, then we add a cell with complex text, then another paragraph and finally another table, here is the result on the final document.
Fluent interfaces like these fully benefit from intellisense and are really simple to use.
alk.
Tags: fluent interface
E-Book on data structure and algorithms
My italian friend Luca Del Tongo had just published an ebook on Data Structure and Algorithms. The book is free to download and it is supported by code examples at http://codeplex.com/dsa.
The argument is really interesting and I suggest you to download and read it 
Alk.
Tags: Algorithm
Next Page »