Due to the overwhelming success and positive reviews of the last STP Online Summit: Business Value of Performance Testing, we've decided to do it again -- only this time, we're going to explore Achieving Business Value with Test Automation.

Join me (while I continue practicing my radio host skills for my emergency back-up career as a sportscaster) and 7 other presenters that I consider to be elite practitioners, teachers, and thinkers in their test automation areas of specialization for 3 half days online to learn their tips and methods for achieving business value with test automation. If you or your organization are using, or thinking about using, automation to enhance or improve your testing, you're not going to want to miss this online summit. I honestly can't think of anywhere else you can get this concentration of relevant and thematically targeted information at a better price, but you be the judge:

When: Tuesday October 11 10:00AM - Thursday October 13 1:30PM PST

Cost: $195 USD before 9/26/11 $245 USD after 9/26/11

Theme: For more than 15 years organizations have been investing in the promise of better, cheaper, and faster testing through automation. While some companies have achieved demonstrable business value from their forays into test automation, many others have experienced questionable to negative returns on their investments. Join your host, Scott Barber, for this three day online summit, to hear how seven recognized leaders in test automation have achieved real business value by implementing a variety of automation flavors and styles for their employers and clients. Learn how to answer the ROI question by focusing on business value instead of testing tasks, and how to implement automation in ways that deliver that value to the business, not just to the development and/or test team.

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.