Today I continue to talk about why rather than how. Different sources (academic, military, etc.) define the 3 (or 4) test levels: Unit, Integration, System (and UAT). I’ve yet to see any unambiguous definition that anyone agrees with… I wonder why military one is most accepted in industry… But I don’t really care. I care not to miss defects. I would like to look at tests levels from this prospective...

It's funny... people ask me why I like testing... This is an excellent example... small, digestible but makes the point...

I often find it more challenging to test something rather than make something...

Remember my first post on Perl Unit Testing ?

Well, I was getting fed up of being forced to have a set_up and tear_down in every test - whether I needed them both or not!

In a previous post on Perl Unit Testing I illustrated one way of improving the readability of Test::More tests.

Subsequently, I remembered that Perl allows you to remove clutter by selectively not using parenthesis. This makes the tests read even more cleanly if omitted from the frist and last lines:

        test 'foo can't be demoralised' , sub {
		$foo->set_bar( HIGH );
		
		throws_ok ( sub { 
			$foo->set_bar( LOW ); 
		} , 
		qr/Should not let others lower the bar/ ,
		'Should not allow lowering of bar');
		
		ok( $foo->is_high_achiever , 
                    'Should still be a high achiever' );
	};

All I have done is remove two parenthesis but it makes the code much easier on the eye... IMHO

Rija Menage then found two very similar CPAN modules:...

I've spent some time working with a client that does extensive development in Perl. They also use Test::More as their test framework. It wasn't my role to evaluate the use of Test::More, not to mention that there was already a significant investment in using it. So, I dived straight in.

Now, having never written any Perl before and being used to XUnit frameworks (specifically NUnit and JUnit), I was used to a very different style of writing tests.

Test::More, unlike many XUnit Frameworks, is a self-sufficient script that requires no test-runner. I've found that many of unit tests written using Test::More were long sequences of method calls and assertions separated by comments. For example...

[textile]About 9 months ago, I spent some time with one of the guys from Agitar, looking at their Agitator product. I held back from recommending it to a client because the client was just getting to grips with Test Driven Development.

"If only you could use it to turn its observations into JUnit Tests. What a great way to plug any gaps you might have left in your own tests!?!?!?" I thought. I envisaged the team writing their code Test-Driven and then using Agitator to plug any gaps they might have left.

I just wanted to bring everyone's attention to JUnitPerf, a set of decorators for JUnit to provide a simple means to acquire timings, and do paced-threading. Essentially implementing bare-bones performance testing in the Junit framework.


Mike Clark is credited with this gem. No relation.
http://www.clarkware.com/cgi/blosxom/2003/

Unit testing was integrated into the software development process of a five-member programming team using a test-during-coding training module. The training approach and module are briefly described. Individual and pair developer performance was measured before and after the training module was presented. The improvements in
quality achieved by the team ranged from 38% to 267% fewer defects.

[textile]Chris McMahon "writes an entertaining article":http://chrismcmahonsblog.blogspot.com/2005/12/but-it-works-on-my-machine.html
about an interesting problem with a unit test. He explains the problem and identifies the appropriate solution. Despite this, there are still several interesting problems with the test.

h2. Living in the Here and DateTime.Now!

The test was a unit test for a Class called Range :