The Disco Blog

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?

Trackback this Post | Feed on comments to this Post