testingReflections.com - unit testing

STP Online Summit: Achieving Business Value with Test Automation

Tue, 23 Aug 2011 16:11:25 +0100

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.

Test levels: why should we care?

Wed, 09 Jan 2008 16:03:49 +0000

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...

Perl Unit Testing... and there's Test::More... optional set_up & tear_down

Thu, 14 Aug 2008 16:02:58 +0100

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!

Perl Unit testing... Test::More and Test::Group

Thu, 14 Aug 2008 15:57:41 +0100

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:...

Perl Unit Testing... Test::More (or less) like XUnit

Thu, 14 Aug 2008 15:51:42 +0100

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...

AgitarOne - generating JUnit Tests... but there is a price to pay...

Wed, 29 Nov 2006 22:07:46 +0000

[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.

JUnitPerf, try it!

Thu, 27 Jul 2006 21:27:12 +0100

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/

Integrating Unit Testing Into A Software Development Teams Process

Thu, 16 Feb 2006 09:04:59 +0000

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 inquality achieved by the team ranged from 38% to 267% fewer defects.

Temporal Anomalies in the DateTime Continuum

Wed, 11 Jan 2006 10:29:26 +0000

[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 :

Introduction myself

Tue, 08 Nov 2005 18:40:13 +0000

I use at the moment Python to write test script!

Unit test readability should not come in place of maintainability - they go hand in hand

Fri, 05 Aug 2005 20:08:41 +0100

Brian Button writes this post about a best practice he believes in when writing unit tests. The main idea in that post is that when you use Setup and TearDown methods in your tests, you're essentially separating parts of the unit tests into 2 or three areas in the class, thus making the person reading the tests more likely to miss out on some subtleties inside the test method.

Unit Testing Best Practices

Fri, 05 Aug 2005 19:01:55 +0100

Someone asked me about this the other day - there are currently no concrete set of guidelines for unit testing best practices (not talking about HOW-TOs, but about HOW_NOT_TOs). So it occurred to me that I've been keeping such a list on this blog for a while now (I keep adding whenever I get the time to post something new to it) only its buried on the left side of my blog page. So, you can get the full list here: http://weblogs.asp.net/rosherove/category/9834.aspx?Show=All There's also an RSS feed especially for that if you'd like on that page. I'm working on publishing an article on this topic (some sort of a top-10 tips for better unit tests) for MSDN Magazine so I'm holding off some of the content, and it's killing me I swear.

Should we be doing more unit testing?

Sun, 12 Jun 2005 15:52:54 +0100

Quick feedback. More testable code. Finding serious problems early. What's not to like? Michael Kelly pleads the case for unit testing. Author: Michael Kelly Published: InformIT, June 3, 2005

Simplify Data Layer Unit Testing using Enterprise Services

Thu, 19 May 2005 06:38:26 +0100

Despite all the hype surrounding unit testing and Test Driven Development (TDD) many developers don't see them as useful processes that are applicable to the production of real-world applications. One reason is that once you get down to the intricacies of application development, all of the easy testing you've heard so much about can vanish. You may find yourself writing unit tests that are hard to implement against real code. This is often the case in database testing, where TDD can quickly lose its appeal, and force you to revert your processes to the previous real-world methodologies your team employed. Here, I'll present some techniques to make your testing process easier, even when developing real-world applications, using unit testing.

Making your tests withstand design and interface changes - remove code duplication

Mon, 11 Apr 2005 06:19:02 +0100

One of the biggest pitfalls developers writing unit tests face is in the face of a re-design. They write hundreds of unit tests for various classes, and suddenly a design change breaks many of them - a default constructor is removed, parameters are added or removed from interfaces, various default conditions change - havoc rears its ugly head. The poor developer is then faced with "fixing" hundreds of tests just because a method was added to a constructor.