Professional Documents
Culture Documents
By jonasbn <jonasbn@io.dk>
Test
QuickT ime and a T IF F (Uncompressed) decompressor are needed to see this picture.
My test definition
Tests can assure me that what I am coding works correctly Tests are aiming at being automated Test is a tool to help my development Tests can be difficult to develop correctly
Coverage Test
Simple Philosophy
All lines should be run at least once Testing all possible branches of the code Time consuming Large number of tests Difficult way of testing Tools to assist coverage test exist
Smoke Test
From the world of electronics
Power it up - does it break? Not much detail Crude way of testing
Integration Test
When things need to be assembled
Known from large projects For dispersed development When integration with 3rd. Party components
Acceptance Test
When the Client/Customer are to approve
Should not replace Performance Test Should not replace automated testing Should not be automated - this is a manual process
Regression Test
When old things are revisited
Used to ensure backwards compability
Stress Test
When trying to break the system
Resembles smoke test Also known as monkey test Changing environments Garbage Feeding
Performance Test
When speed is the need
For benchmarking Can be used to identify bottlenecks History is important
Unit Test
The foundation of all testing
Can be used to implement almost all test methods Simplicity SMOP Can be automated Programmatic approach
Test - Strategy and Implementation
Test Strategy
Melchett: You look surprised, Blackadder. Edmund: I certainly am, sir. I didn't realise we had any battle plans. Melchett: Well, of course we have! How else do you think the battles are directed? Edmund: Our battles are directed, sir? Melchett: Well, of course they are, Blackadder -directed according to the Grand Plan. Edmund: Would that be the plan to continue with total slaughter until everyone's dead except Field Marshal Haig, Lady Haig and their tortoise, Alan? Melchett: Great Scott! Even you know it! Guard! Guard! Bolt all the doors; hammer large pieces of crooked wood against all the windows! This security leak is far worse than we'd imagined!
Test - Strategy and Implementation
Project Goals
We need to examine the projects goals to make the right test strategy The test strategy should support the projects goals not work against them
Defining a strategy
We apply a selection the listed test methods to form a strategy
Which ones should we pick?
An example - Waterfall/Phasedivided
Unit Test during development Smoke Test when building Integration Test when partially done System Execution Test when done Acceptance Test
Other Strategies?
What strategy do YOU use?
Test Implementation
Acceptance Test
Acceptance Test is a manual process and should therefore not be automated Unit Test reports can add some color to the delivery though underlining the fact that the product/system has been tested
Coverage Test
Devel::Coverage Devel::Cover
Smoke Test
Perl smoke testing worth a study
Integration Test
You can easily test this if you take a Smoke Test approach
Regression Test
Regression Test will be necessary at some point Save and use old tests, dont throw anything away
Stress Test
Just bombard your application with calls from your test suite Your test suite will cover all aspects of your application Do it structured Examine the output
Performance Test 1
Benchmark is your friend Save reports, historic data is essential Examine output And compare output
Performance Test 2
use SOAP::Lite; use Benchmark; my $t0 = new Benchmark; my $proxy = "http://somemachine/tempuri/Service1.asmx"; my $uri = "http://service.domain.dk/"; my $soap = SOAP::Lite ->uri($uri) ->proxy($proxy) ->on_action(sub {join '', @_}); my $method = SOAP::Data->name('getcustomer')->attr({xmlns => 'http://service.domain.dk/'}); my @params = (); push(@params, SOAP::Data->name('dslid' => 'dsl89305')->attr({'xsi:type' => 'xsd:string'})); my $rc = $soap->call($method => @params)->valueof("//getcustomerResponse"); my $t1 = new Benchmark; my $td = timediff($t1, $t0); print "the code took:",timestr($td),"\n";
Databases
Database encapsulations can be tricky to test Data is often volatile and a baseline is difficult to optain
The Frame-work
Too many tests Redundant code all over the place Programmatic Practice SMOP
The Frame-work 2
my %data_map = ( message => { type => 'xsd:string', value => kdplg', }, ); my $test_target = 'addtolog'; my $proxy = "http://webservice/Service1.asmx"; my $uri = "http://webservice.host.org/"; my @api_params = qw(message); my $t = Test::Accept::SOAP->new(); $t->test( 'proxy' => $proxy, 'uri' => $uri, 'test_target' => $test_target, 'api_params' => \@api_params, 'data_map' => \%data_map, );
The Frame-work 3
sub test ($%) { my ($self, %args) = @_; my my my my my my $proxy $uri $test_target $api_params $data_map $soap = = = = = = $args{'proxy'}; $args{'uri'}; $args{'test_target'}; $args{'api_params'}; $args{'data_map'}; $args{'soap'};
unless ($proxy and $uri and $test_target and $api_params and $data_map) { warn "Unable to perform test, insufficient parameters\n"; return; } my $method = $self->methodize($uri, $test_target); my @params = (); foreach my $p (@{$api_params}) { $self->parameterize(\@params,$data_map, $p); } my $rc = $self->exercize($soap, $test_target, $method, \@params, $debug); ok($rc, 'Checking we got something back from the webservice'); my $test_result = $test_target.'Result'; ok($rc->{$test_result}, 'Testing the returned result (shallow)');
References
The C++ Programming Language 2nd. Ed., Bjarne Stroustrup Extreme Programming Explained embrace change, Kent Beck Code Complete, Steve McConnell Testing and Code Coverage abstract, Paul Johnson Test::More POD, Michael Schwern Test - Strategy and Implementation article, jonasbn
Test - Strategy and Implementation