Guest lecture on Laurie Tratt's course on testing at KCL, 2012-12-06.

1. Testing: Python, Java, Groovy, etc.
Prof Russel Winder
http://www.russel.org.uk
email: russel@winder.org.uk
xmpp: russel@winder.org.uk
twitter: @russel_winder
Copyright © 2012 Russel Winder 1

2. Aims, Goals and Objects
● Look at some practical aspects of testing with
Python, Java, and Groovy.
● Consider some of the practical positives and
negatives of using test-driven development.
†
● Possibly look at coverage as a useful tool for
programmers‡.
†
If time permits. ‡
And a dangerous weapon in
the hands of ignorant managers.
Copyright © 2012 Russel Winder 2

3. Structure
Introduction.
First part.
Short break.
Second part.
Conclusion.
Copyright © 2012 Russel Winder 3

4. Protocol
● Questions or short comments during the sessions
are entirely in order.
● Let me know you have an interjection by raising
your hand, and when I come to an appropriate
pause, I'll pass you the token.
Questions, answers, comments, etc. appearing
to get too long as interjections may get stacked
to be unstacked at a break.
Copyright © 2012 Russel Winder 4

5. Introduction
Copyright © 2012 Russel Winder 5

6. Russel Winder
● Theoretical Physicist: quarks, strangeness, and charm.
● UNIX systems programmer.
● Academic at UCL: parallel programming, HCI, psychology
of programming.
● Professor of Computing Science at KCL: health
informatics, parallel programming. Head of Department.
● Starter of start-ups.
● Independent consultant, analyst, author, expert witness,
trainer.
Copyright © 2012 Russel Winder 6

7. Interstitial Advertisement
Copyright © 2012 Russel Winder 7

8. Projects
● Gant ● GroovyBalls
● GPars ● GFontBrowser
● SCons ● Pi_Quadrature
● GroovyFX ● Sleeping_Barber
● Groovy
● Gradle
OK, so it's all open source.
Copyright © 2012 Russel Winder 8

9. Testing RW Historically
● The FORTRAN years.
● The C years.
● Early Smalltalk and C++ years.
eXtreme Programming
● The Fortran years.
● Early Java years.
● Test-driven Development (TDD) hegemony.
● Feature-Driven Development (FDD).
● Behaviour-driven Development (BDD).
Copyright © 2012 Russel Winder 9

10. A Personal Epiphany
● C codes needs testing.
● C is very difficult re testing.
● Use Python – as long as the C is in a dynamically
linked library (aka shared object).
Copyright © 2012 Russel Winder 10

11. The Two Parts
Copyright © 2012 Russel Winder 11

12. The Terms
● Unit test.
● Integration test.
● System test.
● Acceptance test.
Smoke test.
Mutation test.
Copyright © 2012 Russel Winder 12

13. Unit Test
● Test the functions and methods for correct
behaviour.
May well require use of mocks.
Copyright © 2012 Russel Winder 13

14. Integration Test
● Test that combination of bits of the system
collaborate in correct ways.
Probably needs some use of mocks.
Copyright © 2012 Russel Winder 14

15. System Test
● Test that the system as a whole works as expected.
No mocks at all.
Smoke test – a pre-test to ensure it is
worth running all the tests.
Copyright © 2012 Russel Winder 15

16. Acceptance Test
● Test that the “purchaser” makes to be happy with
the system as delivered.
Used to be crucial, now contracts are usually
not for one-off items, but for annual support.
Copyright © 2012 Russel Winder 16

17. Code under Test
Copyright © 2012 Russel Winder 17

18. The Tools
● Test frameworks:
● Unit testing Programming language
● Integration testing specific.
● System testing.
Acceptance testing usually uses
a different sort of tool, FitNesse
for example.
http://fitnesse.org/
Copyright © 2012 Russel Winder 18

19. Testing: A Backdrop
● Testing as we know it today has its roots in eXtreme
Programming.
● Smalltalk → sUnit
● Python → PyUnit (aka unittest)
● C++ → cppUnit,…
● Java → JUnit
Every language created one or many
xUnit variants on the assumption it was
The right thing to do…
…even when it wasn't.
Copyright © 2012 Russel Winder 19

20. The xUnit Legacy
● xUnit is fundamentally grounded in dynamic
languages – reflection required.
● Static languages like C++ need a very different
approach, hence CUTE, Catch,… using template
meta-programming (aka compile time reflection).
● Static languages like Java, can use annotations – still
reflection based but better.
Copyright © 2012 Russel Winder 20

21. In the Python-sphere
● PyUnit, aka unittest
● py.test, aka PyTest
● Nose, aka nose
There are many others but the above
are the ones that matter.
Copyright © 2012 Russel Winder 21

22. In the JVM-sphere
● Java: ● Groovy
● JUnit3 ● GroovyTestCase
● JUnit4 – JUnit3 in disguise
● TestNG ● Spock
● Scala ● Clojure
● ScalaTest ● clojure.test
● ScalaCheck ● Midje
● Specs2 ● lazytest
Kotlin, Ceylon, Jython, JRuby,…
Copyright © 2012 Russel Winder 22

23. Being In Control
● For all software developments always use a version
control system.
†
● Given DVCSs such as Git, Mercurial, Bazaar, there are
no excuses for not managing development with a
version control system.
†
Distributed version control system.
Copyright © 2012 Russel Winder 23

24. Individuals / Teams
● Single developer projects need no other tools.
● Multi-developer projects need more infrastructure.
Copyright © 2012 Russel Winder 24

25. Continuous Integration
● A process via which all tests are run for all commits
to the mainline repository.
● A continuous integration server monitors the
mainline repository.
Copyright © 2012 Russel Winder 25

26. Team Workflow
Continuous delivery
Deployment Server Continuous deployment
Developer
System Test Server
Mainline Repository
Developer
Developer
Continuous Integration
Developer
Developer
Copyright © 2012 Russel Winder 26

27. Buildbot
● FOSS continuous integration framework written in
Python:
● Single master. http://trac.buildbot.net/
● Multiple slaves.
http://www.scons.org/
http://buildbot.scons.org/
Copyright © 2012 Russel Winder 27

28. Atlassian Bamboo
● Commercial continuous integration server, free to
FOSS organizations, e.g. Codehaus
http://www.atlassian.com/
http://www.codehaus.org/
http://gant.codehaus.org/
Copyright © 2012 Russel Winder 28

29. JetBrains TeamCity
● Commercial continuous integration server.
● Free support for FOSS projects.
● Cloudy.
http://www.jetbrains.com/
http://gpars.codehaus.org/
Copyright © 2012 Russel Winder 29

30. The Process
Green
Fix CUT
Refactor
New Test
Red
Copyright © 2012 Russel Winder 30

31. Test-driven Development
● Never amend your code unless you have a failing
test.
● Unless the change is a refactoring.
Run all your tests often.
Copyright © 2012 Russel Winder 31

32. Refactoring
● Ensure there are no pending commits prior to a
refactoring.
● Run all the tests immediately before a refactoring –
ensure you get a green.
● Run all the tests immediately after a refactoring –
ensure you get a green.
● If a refactoring leads to a red, back out of all the
changes.
● Run the tests and ensure you get a green.
Copyright © 2012 Russel Winder 32

33. Unit Testing and Mocks
● System testing done within a constrained real
system not live.
● Unit and integration testing needs to disconnect
from some resources.
Copyright © 2012 Russel Winder 33

34. A short
Monty Python
moment…
Copyright © 2012 Russel Winder 34

35. Copyright © 2012 Russel Winder 35

36. A Short Coding Dojo
Copyright © 2012 Russel Winder 36

37. Conclusion
Copyright © 2012 Russel Winder 37

38. Testing
● It's what programmers do.
Copyright © 2012 Russel Winder 38

39. Version Control
● It's the way programmers work.
Copyright © 2012 Russel Winder 39

40. Interstitial Advertisement
Copyright © 2012 Russel Winder 40

41. Testing: Python, Java, Groovy, etc.
Prof Russel Winder
http://www.russel.org.uk
email: russel@winder.org.uk
xmpp: russel@winder.org.uk
twitter: @russel_winder
Copyright © 2012 Russel Winder 41