Moving from Ad Hoc Testing to Continuous Test Data with FitNesse

Moving from Ad Hoc Testing to Continuous Test Data with FitNesse

Joris Meerts, 12 November 2014

Moving from Ad Hoc Testing to Continuous Test Data with

FitNesse

Agile Testing Days




about me

• Joris Meerts

• Software tester since 2007

• Capgemini

• www.testingreferences.com

• Context-driven school

• Member of the Dutch Exploratory Workshop on Testing (DEWT)

• @testingref



• The context

• The starting point

• FitNesse

• Java

• Some lessons learned

outline



The context







• Legacy e-commerce database

• Many (190+) complex tables

• Many stored procedures, triggers

• Complex scheduling

• Hardly any functional documentation

• Processing may take days or weeks

the context: the system



• Agile team

• 1 - 2 senior testers

• 4 - 6 senior database developers

• 1 product owner

• 1 scrum master

the context: the team



The starting point



Why automate?



• Ad hoc testing

• No scheduled tests

• ‘Technical tests’ in FitNesse

• No use of development tools for test code

the starting point



• FitNesse, Java, JUnit, Jenkins, Eclipse

• Advanced SQL, PL/SQL

a first time for everything



FitNesse



test architecture



why I would recommend FitNesse

• All purpose tool

• Modularization

• Separating data from tests

• Symbolic links



all purpose tool

• Database

• REST interface

• SSH / Telnet

• FTP

• No GUI automation



• Use of building blocks

• Parameterized includes

modularization





• Include test data in the scripts

• Restrict the use of test data

• Easy to find out where the data is used

• Use scripts to check configuration

separate data from tests



• Symbolic links

• Templates

• Tags

other useful things in FitNesse



Java



or…

how to learn programming in a

nutshell



• JUnit for testing

• Very easy build and deploy

• Eclipse for development

• OpenJPA replacing scattered SQL statements

some wonderful things about Java



Some lessons learned



some lessons learned

• It is not easy to strike a balance between developing test automation and (exploratory) testing.




• Code that is hard to test can really drainthe energy out of the test automation effort.




• Test automation does not become a team effort by placing it in the definition of done.

• Who should write the test code?

https://patternsofproof.wordpress.com/2014/09/14/who-should-write-the-test-code/)



Determination is an important success factor.




• Data is running through the system.

• We are able to observe system behavior.

• We are able to test some features better.

• Test automation catches bugs.

conclusion



• Gojko Adzic - Test Driven .NET Development with FitNesse (2009)

• Stack Overflow

• Bruce Eckel - Thinking in Java (2006)

some useful resources



[email protected]

@testingref

www.testingreferences.com

patternsofproof.wordpress.com

thank you for attending my presentation