The Disco Blog Welcome Guest | Login or Register

The copasetic gurus who brought you NUnit have decided to create a hip new framework dubbed xUnit.net. Clearly, xUnit.net has a lot of compelling features based upon the many lessons learned from having created a rather successful framework (that is, NUnit, man); however, it seems to me that NUnit is as ubiquitous in the .NET community as Disco music is to the general world population (did you know that disco music sales were up 400% in the year ending 1976?).

Is it your bag to switch to xUnit.net or to stay with NUnit, man? I want to know.

If you are using another trippin’ framework instead of NUnit (like MSTest, etc) let me know if you plan on jumping ship as well. And if the term NUnit is strangely foreign to you, man, you may have better luck at the Java test framework poll. As always, copious thanks for participating in this most scientific poll.

If you:

• Want to learn more about Continuous Integration
• Live to disco dance
• Still watch reruns of Saturday Night Fever
• Are curious about Test Categorization
• Use the word “copasetic” in everyday conversations

then you’ll have a hip time listening to these two podcasts:

• Test Categorization — introduces Test Categorization as a technique for reducing software build durations.
• Introduction to Continuous Integration — introduces the basic concepts of Continuous Integration.

In the Age of Aquarius disco never dies man. Dig it?

The dynomite dancers at Quality Labs have released NDbUnit 1.2, which addresses some small enhancements and a few jive turkey bug fixes. They’re still working on Full .NET 2.0 support but the framework appears to work without changes in most scenarios.

If you are curious about NDbUnit, check out the flash tutorial!

As new tests are added to a code base, the build time will invariably increase. As I have written about before, a process of copasetic test categorization can be employed to help manage build times and thus, test frequencies. As it turns out, test categorization is easy to implement in NUnit using the aptly named Category attribute.

While a particular nomenclature isn’t terribly important, I do believe it essential to standardize on a common vocabulary and understand the neat-o concepts related to each. Briefly, I recommend the following three hip categories:

• Unit tests verify the behavior of small elements in a software system, which are most often a single class. A unit test should run to completion (successfully) in a fraction of a second and should be run anytime a build is run.
• Component tests test portions of a system and may require a fully installed system or a more limited set of external dependencies, such as databases or file systems to name a few. Because these smokin’ tests usually have multiple dependencies, they take a bit longer to run and should be run at regular intervals.
• System tests exercise a complete software system. Because these tests exercise an entire system, they are often created towards the latter cycles of development; furthermore, these tests have the tendency to have lengthy run times, in addition to prolonged set up times.

NUnit’s tripping category attribute can be applied to both classes (i.e a TestFixture) and test methods (i.e. a Test). For example, the following C# test, which verifies an object’s Equals implementation, has been categorized as belonging to the unit group.

[Test]
[Category("unit")]
public void VerifyEquals()
{
  Word wrd1 = new Word();
  wrd1.Spelling = "cerebration";
  wrd1.PartOfSpeech = "noun";

  Word wrd2 = new Word();
  wrd2.PartOfSpeech = "noun";
  wrd2.Spelling = "cerebration";

  Assert.IsTrue(wrd1.Equals(wrd2), "words were not equal!");
}

Additionally, an entire class can be associated with a group by declaring the Category attribute at the TestFixture level as demonstrated below:

[TestFixture]
[Category("component")]
public class WordsTest
{
  //.....
}

Once tests have been grouped accordingly, various NUnit runners can be configured to run a selected group or set of groups. For example, configuring a desired group to execute via NAnt is as easy as creating four targets (each relating to a particular group, plus one for all three).

Below, the logic for running all component tests is captured in the <categories> sub-element of NUnit’s <test> element.

<target name="component-test" depends="build">
 <nunit2 failonerror="false">
  <formatter type="Xml" usefile="true" extension=".xml"
       outputdir="${build.dir}/results/component/" />
  <test assemblyname="${build.dir}\bin\${build.config}\words.dll"
        appconfig="mydefaulttest.config">

    <categories>
      <include name="component" />
    </categories>

  </test>
 </nunit2>
</target>

As part of integrating this categorization within a CI system, the frequencies from above are mapped to a particular target- for instance, the unit-test target (which runs unit tests) can be run anytime the CM system changes (i.e. someone checked something in).

Test categorization within NUnit couldn’t be simpler and by segregating tests into logical groups defined by how long they take to run, build times can be kept manageable as a code base’s tests grow. Dig it?

I remember when I first started investigating the .NET platform, I was fairly impressed with the CLI and the notion that code written in C# could be reused in VB.NET and vice versa. It’s been a number of years since the release of the .NET platform; however, it appears more and more superstars, besides the Mono team, are building upon the CLI and producing some copasetic stuff.

Take Boo, for instance, which is a dynamic language (that claims to barrow its syntax from Python but reminds me more of VB at this point) for the .NET platform. The neat-o thing about Boo is that any thing that runs on the CLI can be used within Boo and furthermore, that complied Boo code can be used within other languages, such as C#. This piqued my interest with regards to developer testing.

It seems to me that the #1 establishment excuse for not testing is ostensibly, the lack of time. If through tools and/or frameworks this perceived barrier can be removed or at least lowered then teams can be one step closer to building in quality as they code, rather than waiting for another entity, like QA or worse, a customer, to verify quality.

Because of Boo’s CLI-ness, Boo code can easily use NUnit- attributes and all. Understanding Boo’s syntax is quite easy, especially if you have familiarity with Python and as I mentioned previously, VB. Heck, a working knowledge of Groovy or for that matter, any dynamic language will help.

First of all, Boo follows the Pythonic indent scheme, whereby program structure is determined by one’s smokin’ indentations. Unlike Groovy’s brackets or Ruby’s end statements, Boo has no termination structures. Unlike C#’s using keyword or VB’s imports, Boo uses the Java-esque import statement and further spices it up with the ability to import from a particular assembly and even alias it with the as keyword.

Types are obviously optional and can be associated with a specific type with the as clause. For example, the hip variable fixture below is typed as OleDbUnitTest:

fixture as OleDbUnitTest

Other Boo syntax rules- instantiation doesn’t require new and constants are declared with the Java-esque final keyword. This is just a slice of the Boo syntax pie and surprisingly, the documentation is quite good.

Because it’s my bag, I thought I’d give Boo a spin by using Quality Lab’s NDbUnit along with NUnit to build a simple test case that inserts data via NDbUnit’s API and verifies the information was indeed committed to a database.

As you can see below, Boo is less verbose than normal C#– there are no semi-colons, brackets and fewer type declarations.

import NUnit.Framework
import NDbUnit.Core.OleDb
import NDbUnit.Core
import System.Data
import System
import System.Data.OleDb

[TestFixture]
class WordTest:

 final CONN = "Provider=SQLOLEDB...."
 final SCHEMA = "Dataset2.xsd"
 final XML = "XMLFile2.xml"
 fixture as OleDbUnitTest

 [SetUp]
 def configure():
  fixture = OleDbUnitTest(CONN)
  fixture.ReadXmlSchema(SCHEMA)
  fixture.ReadXml(XML)	

 [Test]
 def VerifyWordTableOle():

  fixture.PerformDbOperation(DbOperationFlag.CleanInsert)
  select = "select spelling from word where word.word_id = 2"

  adapter = OleDbDataAdapter(select , CONN)

  dta = DataSet()
  adapter.Fill(dta, "word")
  table = dta.Tables["word"]

  for row as DataRow in table.Rows:
    Assert.AreEqual("pugnacious", row[0],
	  "word spelling wasn't pugnacious")

Bottom line– this is a groovy language for the .NET platform that enables the quick construction of working code with minimal rules. Keep in mind too, this isn’t the only dynamic language available for those working with the CLI. There is the IronPython project, which is lead by Jython’s Jim Hugunin and even an IronRuby project. It seems to me; however, at this point, for those looking for the quickest mechanism to knock out tests, Boo is probably the front runner as it supports attributes (which it seems at this point, IronPython doesn’t) and therefore NUnit. Dig it?

Quality Labs has released an NDbUnit flash tutorial that shows how to utilize NDbUnit within a hip NUnit test case. NDbUnit is a .NET library for programmatically placing a database into a known state and can be used to increase repeatability within developer tests that interact with a database by ensuring that the database’s state is consistent across the execution of tests.

Check out the copasetic movie and have fun with NDbUnit!