aspose file tools*
The moose likes Testing and the fly likes fitNesse vs junit Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » Testing
Bookmark "fitNesse vs junit" Watch "fitNesse vs junit" New topic
Author

fitNesse vs junit

Jeanne Boyarsky
internet detective
Marshal

Joined: May 26, 2003
Posts: 30537
    
150

In Robert C Martin's column in Software Development (Dec 2004 edition), he walks through a TDD exercise using FitNesse. He writes that these are for acceptance testing, which corresponds to what I've read about FitNesse.

However, there is no mention of Junit in the article. Is FitNesse something to be used instead of or in addition to junit?


[Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Blogging on Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, OCAJP, OCPJP beta, TOGAF part 1 and part 2
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
FitNesse (and Fit) tests are indeed supposed to be acceptance tests and thus they are not a replacement for unit tests.


Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Correct.

Acceptance Tests are specified, and ideally even written, by the domain expert(s) (what XP calls the Customer). They are written before or in the iteration they are implemented, and you typically want to see pass more and more of them during an iteration, so that they pass all at the end.

Programmer (Unit) Tests are specified by the developers and are written while the code is developed. You typically want them *all* to pass at *any* time in the iteration. They are also typically much more fine grained that Acceptance Tests.

The Programmer Tests give the developers confidence that the code is doing what they think it is doing. The Acceptance Tests give the business people confidence that the system is doing what they need it doing.

Does that help?


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Jeanne Boyarsky
internet detective
Marshal

Joined: May 26, 2003
Posts: 30537
    
150

Yes. Thanks for clarifying this for me.
Rastislav Svoboda
Greenhorn

Joined: Nov 19, 2009
Posts: 2
I like the idea of acceptance testing.
I'm already using TDD for unit testing (C# code using nUnit framework)
But I have problem to do Acceptance Tests (using fitnesse) because our system is asynchronous.

We develop a VCS (Voice Communication System) application and it's based mostly of request - reply communication.

It's not like all synchronous examples I've seen
like Assert.AreEqual(4, calc.Add(2, 2))

but I have something like System.MakeCall("123456")
and after some time I want to verify that call with number "123456" is built and it's in ringing state.

In unit testing, I separate layers, using mock and testing the class in isolation.
But for acceptance test I think I have to test business value of the system end-to-end (no fakes, mocks), right?

What are the best practices to test asynchronous stuff?
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Rastislav Svoboda wrote:I like the idea of acceptance testing.
I'm already using TDD for unit testing (C# code using nUnit framework)
But I have problem to do Acceptance Tests (using fitnesse) because our system is asynchronous.
[...]
but I have something like System.MakeCall("123456")
and after some time I want to verify that call with number "123456" is built and it's in ringing state.


Yes, when testing asynchronous systems you typically don't get the immediate return value to make assertions against. In these cases, you need to make such an API for your tests.

The quickest way to get such asynchronous systems under test is to have the tests "sleep" for N seconds after invoking an operation (where N is a suitable number for that particular operation). This is quickest, yes, but definitely not a good practice - because it 1) makes your tests brittle and unreliable as they break every now and then because the execution took longer than usual, and 2) because it makes your tests go slower than they need to (the sleep has to be way above the average duration of the asynchronous operation in order to avoid false positives).

This is why you need to build some kind of a hook into your system that the tests can wait on. In pseudo-code, I'd probably like to see something like this:



Rastislav Svoboda wrote:In unit testing, I separate layers, using mock and testing the class in isolation.
But for acceptance test I think I have to test business value of the system end-to-end (no fakes, mocks), right?


It would be nice to have your system tests execute against a system that's identical to the production environment. However, if the cost of having that is that I only get to run those tests once a day because they're so damn slow (or whatever), I'd much rather test against a system that's mostly identical to production. Of course, in this situation I'd also want to know exactly how the system is different (i.e. what kind of hooks are being used and how, which components have been replaced and with what, etc.).
Rastislav Svoboda
Greenhorn

Joined: Nov 19, 2009
Posts: 2
Thanks for hints

I've did some "asynchronous extensions" for nUnit
(Inspired by the book Growing Object-Oriented Software, Guided by Tests, Chapter 27 - Testing Asynchronous Code)
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: fitNesse vs junit