Test Driven Development in One Page or Less

Introduction

I was writing a co-worker to explain TDD. It ended up being a short and sweet guide to test driven development that I wish I had when learning TDD so I decided to share it. This is barely a starting point for TDD. I suggest reading "Test Driven: Practical TDD and Acceptance TDD for Java Developers" (even if you don't write in Java). Amazon.ca link here

If you would like a sample project for each step including tests, please leave a comment.

Development Environment

Refactoring support is crucial because you do it so often with TDD. When developing with Flex Builder (no refactoring other than rename), it was very painful and I caught myself skipping steps.

I prefer to use Visual Studio 2008 Professional (C#) + Resharper + NUnit.

NetBeans + JUnit works well and it's free.

I'm sure IntelliJ Idea is also a nice environment.

TDD In One Page

• You write out requirements in a certain way that makes producing tests from the requirement very easy. As you develop, you may think of new requirements (what if I pass in null?) so you add these to your list but don't start them right away unless they are the next best test to develop.
• Then you start with your test class and write your first test function.
• Then you instrument the class you intend to write before writing it.
• Since your tests are very basic and you start with the easiest one first, this should be short and sweet.
• Then you write the class with an empty method (just to pass compilation), and run your test. It should fail because you're probably not testing doing nothing.
• Then adjust the class in the simplest way possible that adds value. So for this one, we just want to make it pass. Return the expected value and viola! You're green.
• Now refactor (no need here - with this example)
• Continue with your next test
• This time you're looking at a different aspect of the same function. If we were making a function that returned string length, the first test may have been: when I pass in a null, I expect a NullPointerException. Now we may be expecting a 0 when an empty string is passed in.
• Run test (red - expected 0, got NullPointerException)
• So adjust the function to test for null & throw an exception, otherwise return 0. It still adds value because now we test for null.
• Run tests (green)
• Now refactor (no need here)
• Add a test for a single character string.
• Run tests (fails - expected 1, got 0)
• So adjust the function to return the string length rather than 0.
• Run tests (green)

As you can see, TDD is about Red, Green, Refactor, next test.

So What Do We Have Here?

At this point you have some great tests that stay with the project forever and didn't take long to write. Your code is clean and easy to use.

Without TDD, you may not have accounted for (or documented) what happens when you pass a null parameter into this function. We all get busy and working fast causes oversights such as this... ones that you will pay for later. *haunted house sounds*

More Complex Behaviors

If your function is more complex than this one, refactoring may bring pieces of the logic into private methods. These private methods still have test coverage which is why TDD is better than Unit Testing after the fact.

It could also become a new class. If so, you either pretend the class already exists (create a stub for now) or create the new class as if it were now the starting point and write tests for the new class first then integrate it back into your first class when finished. I prefer the 2nd method.

Your Implementation (not test code)

// first pass
int GetStringLength(string str)
{
throw new NullReferenceException();
}

// second pass
int GetStringLength(string str)
{
if (str == null)
{
throw new NullPointerException();
}

return 0;
}

// third pass
int GetStringLength(string str)
{
if (str == null)
{
throw new NullPointerException();
}

return str.Length;
}

When NOT to Unit Test

I may get some arguments here but TDD should be avoided when dealing with UI code. That said, Model, View, Presenter is a great pattern if you want to test the code directly behind the UI. Testing the front-end is not very productive unless you absolutely have to.

Finishing Up

Hope this helps at least one person figure out what TDD is all about. I found it to be faster to develop with because I wasn't troubleshooting bugs, my code was always clean, and I knew exactly what to do next.

Flex 3.4 Illegal override of FlexModuleFactory

An important note for those switching from Flex 3.2 to Flex 3.4

If you have css styles which were compiled (likely in FlexBuilder), you must re-compile them with the Flex 3.4 SDK to get rid of this error.

Line Causing Error

StyleManager.loadStyleDeclarations("yourexternalstyles.swf");

Exact Error Message

VerifyError: Error #1053: Illegal override of FlexModuleFactory in mx.core.FlexModuleFactory.

at global$init()

Help with "ref" and "out" in C# .NET 3.5 2008

In this article, I will discuss the out keyword and the ref keyword in C Sharp. These should be used sparingly but are handy in certain situations (especially when dealing with structs and sorting).

If you do not understand pointers yet, I would advise steering clear of these.

Similarities to other languages

Both "out" and "ref" mean pass the variable into the function "by reference".

If you are a VB6 guru, this is similar to the "ByRef" keyword.

If you're a C++ writer, you would use the address of operator "&" (if you did not already have a pointer to the object) and the function would have "*" following the data type.

There is no such modifier in Java.

What do they mean?

Out and ref extend the meaning of "by reference" by additionally stating that the variable must be initialized and will be modified (ref) or that it will be initialized inside of the function (out).

The default (no prefix to the parameter) is a "by value" copy of a structure/simple data type or a "read-only reference" of an object meaning you cannot change where it points to but you can change the variables inside of the class. This is how Java works.

The "ref" Parameter Modifier

• "ref" is by reference
• It does not give a compiler error if it was not passed in the argument list for the function
• It gives you the ability to modify the pointer of the original object
• It is a great way to pass structures around in code because it does not make a "by value" copy of them
• Parameter must be initialized before calling the function
• "ref" prefix exists when defining the function and when calling it (making it obvious that this is a by reference call)

Example of By-Reference Parameters in C#

public void SimpleSwap(ref String string1, ref String string2)
{

// store the pointer of string1
String temp = string1;

// set string1's pointer to point to string2
string1 = string2;

// set string2's pointer to point to string1 (HINT: this is not pointing to string2)
string2 = temp;
}

// ... code using this ...
String string1 = "ABC";
String string2 = "DEF";
SimpleSwap(ref string1, ref string2);

// string1 now points to "DEF"

// string2 now points to "ABC"

The "out" Parameter Modifier

• "out" is by reference
• The parameter must be assigned or you get a compile error
• A new object is created and returned (the variable you passed in points to the one created inside of the function)
• "out" parameters do not need to be initialized
• This is a great way to fill structures
• It allows the language to safely handle multiple return values without the need for new objects/structs
• "out" prefix exists when defining the function and when calling it (making it obvious that this variable will be initialized by the function call)

Example of a Function Returning Multiple Values in C#

public void GetCoordinates(out int x, out int y)
{

x = 5;

y = 9;

}

// ... code using this ...
int x;

int y;

GetCoordinates(x,y);
// x is now 5

// y is now 9

Conclusion

Out and ref are great tools when you need them. I hope this article helps you understand more about how they work.

Note: I use the terms "keyword", "modifier", and "prefix" when discussing ref and out. The actual term (AFAIK) for these is "modifier".

Note: Code examples in this article are incomplete and will not compile. If you require complete examples, please leave a comment and I will post them for everyone.

Why can't I import javafx.ui.*?

The Answer for the Impatient (like me!)

Short answer for those who are impatient... see javafx.scene.layout.* and use something like HBox. Reason you ask? JavaFX 1.1 vs 1.2 had many non-backwards compatible changes.

Background

So I was trying out JavaFX with NetBeans 6.5.1 while I was waiting for a software build to complete. I created a simple project then wanted to do a more advanced component layout. I Googled "javafx positioning elements side by side" and noticed that many of the tutorials were importing javafx.ui.* to get BorderLayout. Looks great!

Absolute Positioning

Before I continue, here is my code which has a simple Text and an ImageView component:

/*
* Main.fx
*
* Created on Jun 8, 2009, 9:50:23 AM
*/

package javafxapplication1;

import javafx.stage.Stage;
import javafx.scene.Scene;
import javafx.scene.text.Font;
import javafx.scene.image.Image;

import javafx.scene.image.ImageView;
import javafx.scene.text.Text;


/**
* @author graeme
*/

Stage {
title: "Flask"
width: 800
height: 600
scene: Scene {
content: [
Text {
font : Font {
size : 16
}
x: 10
y: 30
content: "Flask 0.01"
}
ImageView {
x: 10
y: 50
image: Image {
url: "{__DIR__}flask-2.jpg"
}
}
]
}

Adding the Infamous BorderLayout

I simply added BorderLayout inside of my scene content and did the old CTRL+SHIFT+I to fix imports and... nothing. Confused++

So I typed the import in manually and noticed it was not there. Confused++

I figured I had an old version of NetBeans. So I went to get NetBeans 6.7 RC2 and JavaFX is not available for it... Confused++

Maybe my Plugin was old...? I checked - nope! Brand new. Confused++

Here is the code that will not work in JavaFX 1.2 - I have bolded the reasons why:

/*
* Main.fx
*
* Created on Jun 8, 2009, 9:50:23 AM
*/

package javafxapplication1;

import javafx.stage.Stage;
import javafx.scene.Scene;
import javafx.scene.text.Font;
import javafx.scene.image.Image;


import javafx.ui.*;

import javafx.scene.image.ImageView;
import javafx.scene.text.Text;


/**
* @author graeme
*/

Stage {
title: "Flask"
width: 800
height: 600
scene: Scene {
content: [
BorderLayout {
content: [
Text {
font : Font {
size : 16
}
content: "Flask 0.01"
}
ImageView {
image: Image {
url: "{__DIR__}flask-2.jpg"
}
}
]
}
]
}
}

Breaking Through the Confusion

So now that Confused = 4, I Googled once more. (Rhyming not intentional)

I read that many classes moved from javafx.ui.* to javafx.application.* then distributed somewhere inside to javafx.scene. This makes more sense!

So I found HBox and VBox (which are quite familiar to me in the Flex world) and gave those a shot. Worked like a charm!

Here is the code that will work in JavaFX 1.2:

/*
* Main.fx
*
* Created on Jun 8, 2009, 9:50:23 AM
*/

package javafxapplication1;

import javafx.stage.Stage;
import javafx.scene.Scene;
import javafx.scene.text.Font;
import javafx.scene.image.Image;


import javafx.scene.layout.HBox;

import javafx.scene.image.ImageView;
import javafx.scene.text.Text;


/**
* @author graeme
*/

Stage {
title: "Flask"
width: 800
height: 600
scene: Scene {
content: [
HBox {
content: [
Text {
font : Font {
size : 16
}
content: "Flask 0.01"
}
ImageView {
image: Image {
url: "{__DIR__}flask-2.jpg"
}
}
]
}
]
}
}

Screenshot of NetBeans 6.5.1 Flask Example















References

Good ones:

http://java.sun.com/javafx/1/tutorials/ui/layout/index.html#hbox
http://java.sun.com/javafx/1/tutorials/ui/

Old ones:

http://www.ibm.com/developerworks/java/library/j-javafx/
http://www.informit.com/guides/content.aspx?g=java&seqNum=418