The Disco Blog Welcome Guest | Login or Register

This is totally mind-blowing, baby: via boojay (an extension to boo, which is a hip alternate language, based on Python, for the .NET platform) you can produce valid Java byte code. To my knowledge, this is a first– via an alternate language running on one platform, you can produce valid code for another target platform (i.e. .NET -> Java).

For instance, the author of boojay has already demonstrated how to create an Eclipse plug-in in boojay. Of course, there are plenty of copasetic languages for the JVM that produce Java byte code– Groovy, JRuby, Jython; however, these languages can’t (directly) produce valid byte code for the CLR. Is anyone up to this (oh so spooktacular, baby!!) challenge, man?

If it’s your bag and you want more information on Boo, check out:

• Boo is groovy too (thediscoblog.com, May 2006)
• Boo is groovy two (thediscoblog.com, June 2006)
• Much ado about Boo (InfoQ.com, March 2007)

About a year ago, I started looking deeply into boo, which is a Python inspired language targeting the .NET CLI that enables rapid development of compliant Windows applications. With boo, you can quickly write developer tests, build GUIs, prototype applications– you name it– this language is frighteningly simple, man. Check out InfoQ’s “Much ado about Boo” and see for yourself how with its relaxed syntax, boo is a convenient platform for doing just about anything on the .NET platform quickly.

As I’ve previously written about, developer testing with Boo can facilitate authoring tests quicker due to Boo’s relaxed hip Python-like syntax. Boo also integrates nicely with NAnt, meaning that tests written in Boo can easily be plugged into an automated build system that:

1. compiles Boo code into a normal .NET assembly
2. runs the corresponding NUnit tests
3. reports the results

Compiling copasetic Boo code involves a bit a magic at this point as the current release doesn’t play well with the latest version of NAnt; therefore, in order to get things working properly, I had to use an older version of Boo (0.7.5) and NAnt 0.85-rc2. Once I had the correct versions, things moved quickly from there.

First, I had to load the Boo NAnt tasks with NAnt’s loadtasks task:

<target name="init">
  <loadtasks assembly="C:\\dev\\tools\\boo.0.7.5\\bin\\Boo.NAnt.Tasks.dll" />
</target>

Next, the booc task complies all Boo files into a .dll- in my case, I had to reference some additional love power libraries. For instance, I had to reference some .NET system libraries, which I would have figured the .NET runtime would have figured out (I’ve never had to reference a Java system library (rt.jar) when compiling Java or any of its manifold supported languages).

<target name="build" depends="init, setup">
  <booc target="library" output="${build.dir}/boo.words.dll">
    <sources basedir="src">
      <include name="**/*.boo" />
    </sources>
    <references basedir="./bin">
      <include name="nunit.framework.dll" />
      <include name="NDbUnit.Core.dll" />
      <include name="System.dll" />
      <include name="System.Data.dll" />
      <include name="System.Xml.dll" />
    </references>
  </booc>
</target>

Lastly, once things are compiled, the test target runs the compiled NUnit tests. Note, for some reason, the NDbUnit assembly must be in same directory where the compiled assembly resides in order to the tests to properly run.

<target name="test" depends="build">
 <copy todir="${build.dir}">
  <fileset basedir="./bin">
   <include name="NDbUnit.Core.dll" />
  </fileset>
 </copy>

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

Boo’s smokin’ integration with .NET (and NAnt) makes this a compelling platform for building tests rapidly. 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?