Wiki Home

Unit Testing


Namespace: WIN_COM_API
Unit testing is a software development concept that refers to the basic testing of a piece of code, usually a function or subroutine. Unit Testing is generally performed by developers.
So, can Testing By Poking Around be a form of Unit Testing? -- Randy Jean (See Design By Contract)

Unit Testing drives the development. You write the tests, one at a time, as you write the code. Your first test, which fails initially, is made to pass by adding the function and simply returning the answer. Then you add a second test and generalize your code to pass both items. Add a third and make them all pass. In this way you change your code just enough to pass test items as a set and actually watch the code go from a state of 'unknowing' to 'knowing'.

The paragraph above describes (roughly) Test Driven Development (TDD). A "Unit Test" is, I believe, a broader term for component-based tests that developers write. The Unit Test is the fundamental currency in TDD, but writing Unit Tests does not mean you are doing TDD. - ?lc
---
Can anyone suggest a good VFP-based unit testing framework along the lines of jUnit for java? -- Bruce Onder

Take a look at Fox Unit, http://www.foxunit.org/. It's free and open source and it was modeled after jUnit/nUnit. -- Russ Swall
Christof discusses unit testing and Fox Unit in the current (August, 2006) issue of FoxPro Advisor.


I saw a demo of Fox Runner by Manfred Ratzmann at DevCon Germany 1999 and it was really slick. He's got an article related to this in FoxPro Advisor within the last 6-8 months.-- Steven Black

Great, I'll look into it. I also ported the simple java framework at the Extreme Programming site to VFP. Only took a couple of hours. It works, but if there's something more full featured, then I want it! :) -- Bruce Onder
NUnit - http://nunit.org/default.htm
What Is NUnit?
NUnit is a unit-testing framework for all .Net languages. Initially ported from JUnit, the current version, 2.0 is the second major release of this xUnit based unit testing tool for Microsoft .NET. It is written entirely in C# and has been completely redesigned to take advantage of many .NET language features, for example custom attributes and other reflection related capabilities. NUnit brings xUnit to all .NET languages.
Some Unit Testing walkthroughs can be found on http://www.xprogramming.com/xpmag/acsIndex.htm
Another Unit testing framework: csUnit at http://www.csunit.org/index.html
csUnit offers a command line, a graphical runner, and an addin for Visual Studio. Futhermore it recently has added support for multiple categories and timeout on tests. csUnit has been written in C#, but it can be used with all .NET languages. Test are detected either based on naming conventions (JUnit 3.8 style) or attributes (.NET style). On a decent notebook, csUnit executes over 6,000 tests per minute. Recently csUnit has also been significantly improved in terms of quality and usability.
Check out 'Test Driven Development' by Kent Beck. ISBN 0321146530.

Kent walks you through a detailed TDD example with multiple currencies, test drives the development of a testing framework, and extends discussions in the third part of the book. I followed the test framework development in Fox and was amazed at the similarity between the language Kent chose to use (Python) and Fox. After this chapter you'll be ready to make your own!

I use these techniques every day and love them for their fast cycle times, easy progess and secure feelings when making changes to old code. And I love to grow a solution with an ever increasing test set. Joe Kuhn

Hey Joe, I just implemented Kent's xUnit in VFP myself (highly reccomended excercise) and have a question for you. It has to to with the difference between a Test Failure (where the ASSERT fails) and an Error (where your code fails due to syntax etc). xUnit traps and reports both which I'm sure is just fine in a IDE-less environment. But I'd rather NOT wrap the test method call in a TRY/CATCH and just let the errors fly so I can suspend go to the debugger etc. On the other hand, I can imagine you'd want to simply log the errors in a nightly build situation and allow the tests to continue. So, I'm thinking of adding a "halt on error" flag to the TestCase class and then put some branching code in the ::run() method, which currently looks like this:

  *------------------------------------
  function run( toresult )
    local lcMethod, loErr

    toresult.testStarted()
    this.setUp()
    lcMethod = this.Name

    try
      this.&lcMethod
    catch to loErr
      toresult.testFailed( m.loErr )
    finally
      this.tearDown()
    endtry

    return m.toresult


How have you (or others) addressed this Failure vs Error issue? 0- lc (who is finally getting around to standardizing his unit-test building techniques)
Hey Lauren, I'm letting the errors happen so I can take care of them right away. I don't have a try catch in my latest test class. Actually I've been through the second section of Kent's book twice now and have decided to take a bit of a turn after coding a 'minimal' test framework. I'm going to do a gui in the Naked Objects style with just this as a minimal starting point:
DEFINE CLASS Test as Label
FUNCTION Run
	LOCAL lcFunc
	This.Setup()
	lcFunc = "This." + This.Name
	&lcFunc
	This.TearDown()
ENDFUNC
FUNCTION AssertEquals(Expected, Got)
	WITH This
		Expected = TRANSFORM(Expected)
		Got = TRANSFORM(Got)
		ASSERT Expected = Got MESSAGE "Expected '" + TRANSFORM(Expected) ;
                      + "' Got '" + TRANSFORM(Got) + "' in " + This.Name
	ENDWITH
ENDFUNC
FUNCTION Setup
FUNCTION TearDown
ENDDEFINE

FUNCTION RunTest(tcTest)
	LOCAL loT
	loT = CREATEOBJECT(tcTest)
	loT.Run()
ENDFUNC 

The Fox ASSERT is really ugly, but I'll deal with that later.

Kent adds to his test list as he goes and refactors, refactors, refactors. I decided to take my minimalist framework and start using it to develop. As I did I noticed my calls to RunTest() grew quite large and I comment out all but the new test until it's working and then put the rest back in. I can think of a nice interface to let me do this graphically where you drop an object on a form (a label), right click on it and you get a little menu with these options:

Rename
Run

You rename the lable so the caption is the same as the name of your test, write the test, and then run it.

You can drop a 'list' item on the form and drag and drop these 'tests' onto the list. Now that they're in the list you can run them all or drag them back out and run them individually... Joe Kuhn
Sounds nice, I wonder if a pair of tree-view objects would do the trick better as tests can be in suites and suites can be in other suites etc... OIW, Unit Tests can be Composite. That said, I think I've got lots more mileage to get out of my prg-based tools before I move to a GUI. Would be nice to have a real "green bar" though... < s >. - lc
Composite, yes, but it turns out you can't modify test classes once you've instantiated them on a form. So my form objects will have to just be launchers. Launchers should be composites - we'll see though because I have a feeling 'test' and 'list' will be based on very different FoxPro base classes. It may have to be 'manual' composites rather than real inheritance. Joe Kuhn
Lauren - It might be fun to compare what you've done with my first pass - a very literal translation of Kent Beck's test framework section where he test develops a testing framework. Like he says, it's similar to doing brain surgery on yourself. Don't... Oops now you're done. I've posted this translation from Python to FoxPro on the YahooGroups.com site as 'UT.ZIP'. You'll have to join first but you can get the book and the Fox example (go to files section) and then cancel if you don't want chat. Joe Kuhn
Sounds complicated, how about I just mail you mine and vise-versa? < s >
My current plan is to convert all my existing unit tests (which are simple prg-based scripts, on occasion mata-data driven) into the framework. Then, I'm going to fire up Py UnitOffsite link to http://pyunit.sourceforge.net/ and play with it a bit, picking and choosing the features I want to convert to my VFP version. This way I learn some more Python and get some good UT ideas at the same time. - lc
You've converted Py UnitOffsite link to http://pyunit.sourceforge.net/ to Fox or you're converting your Fox tests to Python? Joe
I want to work toward a unit testing framework in VFP that mimics much of what Py UnitOffsite link to http://pyunit.sourceforge.net/ does. Since I intend to add Python to my tool box over the next year, this seemed like a nice synergistic approach to codifying my VFP unit testing. - lc
Ok Lauren. How'd you create the OffsiteLink for Py UnitOffsite link to http://pyunit.sourceforge.net/? Joe
Use a #REDIRECT http://pyunit.sourceforge.net/ on the first line of the Py UnitOffsite link to http://pyunit.sourceforge.net/ topic. This is a Wiki Line One Directive trick.
Unit testing article on MSDN:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnaspp/html/aspnet-testwithnunit.asp
YahooGroups.com has a TestDrivenDevelopment group. You can actually pick up Kent Beck's book in the files section for free and nobody cares. http://groups.yahoo.com/group/testdrivendevelopment
I developed a Unit Test framework for VFP called FUnit, based on a whitepaper defining JUnit. You can fine a description at http://www.glrsoftware.com/funit.asp
Category Testing Category Definitions
( Topic last updated: 2009.12.05 09:55:15 AM )