3. What is a legacy system?
#bgoug2013
You spot an obvious design problem
know how to improve that,
but the thought about consequences gives you a
stomach ache.
source: Gojko Adzic, "Fighting the monster"
3/56
5. Why (automated) testing?
#bgoug2013
Makes application change easier
Safety net - provides confidence/removes fear
Documentation
Help to localize where exactly a defect is located
Reduce the chance of new bugs
Automation enables earlier feedback, saves time,
helps focusing on solving the main problem. (Not
everything is feasible to automate)
5/56
6. Test Fixture
#bgoug2013
All the things we need to have in place in order to
run a test and expect a particular outcome
The test context
6/56
7. System Under Test (SUT)
The system that is being tested
#bgoug2013 7/56
8. Test execution cycle
#bgoug2013
Arrange (set up the Fixture)
Act (exercise the System Under Test)
Assert (verify results are as expected)
Tear Down the fixture (to isolate other tests from
this one)
1.
2.
3.
4.
8/56
9. Unit test
#bgoug2013
Tests small individual unit (module,
procedure/function)
In isolation (no interaction with other units)
Should run quickly (otherwise people won't run
them)
9/56
11. Acceptance test
#bgoug2013
Conducted to determine whether or not a system
satisfies its acceptance criteria
and to enable the customer to determine whether or
not to accept the system.
At least modeled and possibly even written by the
customer
End-to-end (slower than Integration & Unit tests)
11/56
12. Regression tests
(Regress vs progress)
Performed to make sure that previously working
functionality still works after changes elsewhere in
the system
#bgoug2013 12/56
13. Refactor
Is the the process of changing a system in such a way
that
Doing refactoring without tests is unsafe
#bgoug2013
doesn't alter external behaviour
and improves it's internal structure (design)
through small steps
13/56
15. Tests are not the main product in TDD
#bgoug2013
TDD is a design technique
The design emerges in small steps
15/56
16. Why test first?
#bgoug2013
Start with end in mind (think from point of view of
caller)
This perspective helps for better design
Test coverage is useful byproduct
Greatly reduces the need of debugging
16/56
19. Why testing the Database?
#bgoug2013
For lot of businesses, data held in DB are the most
vital commercial asset they have
Business critical functions rely on this data
So it makes sense to validate that data is stored and
processed correctly
19/56
20. Challenges of Database testing...
#bgoug2013
Bad tools
Inherently hard to test. Isolation is difficult
Attitude ("it's not my job")
Too much boilerplate code
OO tools not directly applicable for RDBMS
Changes are persistent
Shared environment
Triggers, Constraints
20/56
21. How to isolate db tests?
Run tests in one transaction
#bgoug2013
Makes them repeatable and independent
When one transaction is not an option - clean up
after tests
21/56
22. How to isolate db tests (2)?
Dedicated database
#bgoug2013
One db per contributor
Separate schemas
Shared Dev db may work too
As a rule - avoid running tests on top of production
22/56
23. Other Tips
#bgoug2013
Make tests self-sufficient
Don't count on the order of tests
Prepare everything you need for the test in its set-up
23/56
25. What is DbFit?
#bgoug2013
Initially created by Gojko Adzic:
Enables manipulating database objects and defining
tests in tabular form
Open source https://github.com/benilovj/dbfit
to enable efficient database testing
motivate database developers to use an
automated testing framework
25/56
26. DbFit, FIT and FitNesse
#bgoug2013
DbFit is based on FIT+FitNesse+DB Fixtures which
enable FIT/Fitnesse tests to execute directly against a
database.
FIT is Acceptance testing framework
FitNesse is Wiki-web based front-end for FIT
customer oriented
tests are described as tables
26/56
28. What is DbFit Fixture?
#bgoug2013
A fixture is interface between:
In general there is 1:1 mapping between Fit table
and fixture
the test instrumentation (Fit framework),
test cases (Fit tables),
and the system under test (e.g. a database
stored procedure)
28/56
29. Why DbFit?
#bgoug2013
Easy to use (even for non-technical people)
Provides all the plumbing:
Runs inside FitNesse - already integrated with lots of
other tools/libraries
Tests expressed and managed as tables
Web-Wiki front-end
Transaction management
Features based on meta-data
Parameter mapping
29/56
30. What is Wiki?
#bgoug2013
The simplest online database that could possibly
work. - Ward Cunningham
Allows users to freely create and edit Web page
content using any Web browser
A group communication mechanisms
Encourages democratic use of the Web and
promotes content composition by nontechnical
users
source: http://wiki.org/wiki.cgi?WhatIsWiki
30/56
31. Fitnesse Wiki
#bgoug2013
Hierarchies - SubWiki, Test Suites
Page types - Suite, Test, Static
Some special pages:
http://fitnesse.org/FitNesse.UserGuide
PageHeader, PageFooter
SetUp, TearDown, SuiteSetUp, SuiteTearDown
Inherited recurively by default; can be overriden
31/56
32. A Unit test with DbFit
#bgoug2013
Set up the input data (arrange).
Execute a function or procedure (act).
Run a query and compare actual vs expected data
(assert).
1.
2.
3.
32/56
35. Getting started
#bgoug2013
Needs Java to run
Download: http://benilovj.github.io/dbfit
Unzip
Copy Oracle JDBC driver (ojdbc6.jar) to lib subfolder
Run the startup script (startFitnesse.sh or
startFitnesse.bat)
Access via web browser - http://localhost:8085
1.
2.
3.
4.
5.
6.
35/56
36. Connecting to the database
Inline configuration:
Using properties file:
#bgoug2013
!|Connect|localhost:1521|username|password|dbname|
!|ConnectUsingFile|DBConnection.properties|
service=localhost:1521
username=username
password=password
database=dbname
36/56
42. Parameters and fixture symbols
#bgoug2013
set parameterto set parameter directly
>>paramname- store a value
<<paramname- read the value
!|setparameter|ONE|1|
!|query|selectsysdatemytimefromdual|
|mytime? |
|>>current_time |
!|query|selectcount(*)cntfromdualwheresysdate>=:current_time|
|cnt |
|<<ONE |
42/56
46. Working Modes of fixtures (2)
Flow mode
#bgoug2013
A DatabaseTest fixture controls the whole page and
coordinates testing
Automatic rollback at the end (manual commit or
rollback is still possible)
Better isolation
Some additional features such as inspections of
stored procedure error results
OracleTest, MysqlTest, DerbyTest, DB2Test, ...
46/56
47. Working Modes of fixtures (3)
Standalone mode
#bgoug2013
We are responsible for transaction management
Enables more control over the database testing
process
Allows using other individual fixtures
We can supply our own database connection to
make sure that (Java) integration tests are running in
the same transaction
47/56
49. Integration test with SQL*Loader
#bgoug2013
Compile CommandLineFixture (by Bob Martin)
Use it to run a shell script
!3LoadsomedatawithOracleSQL*Loader
|com.objectmentor.fixtures.CommandLineFixture |
|command|${PROJECT_ROOT}/loaderdemo/load_employee.sh|
!|Query|select*fromemployee |
|id |name?|dept? |salary?|
|100 |Thomas|Sales |5000 |
|200 |Jason|Technology|5500 |
|300 |Mayla|Technology|7000 |
|400 |Nisha|Marketing|9500 |
|500 |Randy|Technology|6000 |
|501 |Ritu |Accounting|5400 |
49/56
50. Automating tests execution
#bgoug2013
Running tests from command line
Run test or suite as RESTful service
http://fitnesse.org/FitNesse.UserGuide.RestfulServices
JUnit
java-jarfitnesse-standalone.jar
-d"${TESTS_DIR}"
-c"BgougDemoSuite?suite&format=text"
50/56
51. How tests are stored?
#bgoug2013
Simple text files
content.txt - test definition and other Wiki content
properties.xml - metadata (Test, Sute)
Easy to put under version control
51/56
53. Summary
#bgoug2013
Changes of database code and schema are often
relatively hard
This makes the systems considered legacy
TDD stimulates designing cleaner and easier to
change code
Development of RDBMS artefacts is lagging when it
comes to engineering practices and tools
DbFit can help
53/56
54. Resources
#bgoug2013
http://benilovj.github.io/dbfit - with links to:
https://github.com/javornikolov/tdd-with-dbfit-bgoug-201305
http://gojko.net/2007/11/20/fighting-the-monster
http://www.agiledata.org/essays/tdd.html, http://www.agiledata.org
Test Driven Development: By Example, Kent Beck
Refactoring Databases - Evolutionary Database Design, Scott W. Ambler, Pramodkumar J. Sadalage
download DbFit
docs, getting started information
mailing list - don't hesitate to participate and ask questions
code repository at github - reports for problems, suggestions and contributions are welcome
54/56