The Disco Blog Welcome Guest | Login or Register

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?

Most copasetic software architectures are intended to support a system’s extensibility, maintainability, and reliability. Unfortunately, inattention to quality issues (due to too much disco dancing, for example) can easily undermine a software architect’s best effort. The fourth article in IBM developerWork’s series “In pursuit of code quality” explains how to continuously monitor and correct quality aspects of code that can affect the long-term viability of a software architecture.

Check out “Code quality for software architects” and if you have any thoughts, questions, or concerns, check out the “Improve Your Java Code Quality” forum!

Manning publications has released a copasetic early draft of Groovy in Action’s chapter 1 (which can be found on the book’s homepage). The book is due out in November and is shaping up quite nicely. Way to go Manning team!

Often times, applying the Extract Method refactoring technique results in the creation of a hip private method. This certainly creates an interesting testing challenge should you want to actually verify the behavior of that method in isolation. Of course, there are a number of ways to approach this issue:

• Make the method public
• Make the method protected and put the test case in the same package
• Make an inner class, in the parent class, which is a test case

It turns out there is another option as well: leave the method as declared (i.e. private) and use the copasetic JUnit-addons project to test it.

The JUnit-addons project has a few handy utilities that facilitate testing with JUnit; however, definitely one of the most useful is its PrivateAccessor class, which makes testing private methods a snap, regardless of your chosen testing framework. The PrivateAccessor class has no implicit dependency on JUnit; therefore, it can be used in TestNG, etc.

The PrivateAccessor’s API is simple- by providing the name of the method (as a String) and its corresponding parameter types and associated values (in Class and Object arrays respectively) to the invoke method, the value of the invoked method is returned. Underneath the covers, the PrivateAccessor class actually turns off object accessibility using Java’s Reflection API. Keep in mind, however, that if your VM has custom security settings, this utility may not function correctly.

Below, the getStatus method, which has been declared as private in the AccountAction class, is called with both parameters values set to null. The invoke method returns an Object, hence the cast to a String. Also note, the invoke method declares that it throws Throwable, so you either must catch it or let your testing framework handle it, as I’ve done.

public void testGetStatus() throws Throwable{
  AccountAction action = new AccountAction();

  String value = (String)PrivateAccessor.invoke(action,
      "getStatus", new Class[]{IStatus.class, List.class},
       new Object[]{null, null});

  assertEquals("should be No Changes Since Creation",
    "No Changes Since Creation", value);
}

Note, the invoke method has been overridden to either take an Object instance as above or a Class in the case that the desired private method is also static.

Keep in mind that using reflection to invoke private methods does introduce a level of brittleness to the resulting tests. Should someone rename the getStatus method, the above test will fail miserably; however, if tests are run frequently, the appropriate changes can be made quickly to fix the test.

Testing private methods is sure to create a smokin’ debate; however, its nice to know that it can be easily done. Dig it?