Testing: Python, Java, Groovy, etc.

(1)

Testing: Python, Java, Groovy, etc.

Prof Russel Winder

http://www.russel.org.uk

email: russel@winder.org.uk xmpp: russel@winder.org.uk

(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}

(3)

Structure

Introduction.

First part.

Short break.

Second part.

Conclusion.

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

(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,

(7)

(8)

Projects

● Gant ● GPars ● SCons ● GroovyFX ● Groovy ● Gradle ● GroovyBalls ● GFontBrowser ● Pi_Quadrature ● Sleeping_Barber

(9)

Testing RW Historically

● The FORTRAN years. ● The C years.

● Early Smalltalk and C++ years. ● The Fortran years.

● Early Java years.

● Test-driven Development (TDD) hegemony. ● Feature-Driven Development (FDD).

● Behaviour-driven Development (BDD).

(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

(11)

(12)

The Terms

● Unit test. ● Integration test. ● System test. ● Acceptance test. Smoke test. Mutation test.

(13)

Unit Test

● Test the functions and methods for correct

behaviour.

(14)

Integration Test

● Test that combination of bits of the system

collaborate in correct ways.

(15)

System Test

● Test that the system as a whole works as expected.

Smoke test – a pre-test to ensure it is worth running all the tests.

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

(17)

(18)

The Tools

● Test frameworks:

● Unit testing

● Integration testing ● System testing.

Acceptance testing usually uses a different sort of tool, FitNesse for example.

http://fitnesse.org/

Programming language specific.

(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…

(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

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

(22)

In the JVM-sphere

● Java: ● JUnit3 ● JUnit4 ● TestNG ● Scala ● ScalaTest ● ScalaCheck ● Specs2 ● Groovy ● GroovyTestCase – JUnit3 in disguise ● Spock ● Clojure ● clojure.test ● Midje ● lazytest

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

(24)

Individuals / Teams

● Single developer projects need no other tools.

(25)

Continuous Integration

● A process via which all tests are run for all commits

to the mainline repository.

● A continuous integration server monitors the

(26)

Developer Developer Developer Developer Developer Mainline Repository Continuous Integration Deployment Server

Team Workflow

Continuous delivery Continuous deployment

(27)

Buildbot

● FOSS continuous integration framework written in

Python: ● Single master. ● Multiple slaves. http://buildbot.scons.org/ http://www.scons.org/ http://trac.buildbot.net/

(28)

Atlassian Bamboo

● Commercial continuous integration server, free to

FOSS organizations, e.g. Codehaus

http://www.atlassian.com/ http://www.codehaus.org/

(29)

JetBrains TeamCity

● Commercial continuous integration server. ● Free support for FOSS projects.

● Cloudy.

http://gpars.codehaus.org/

(30)

The Process

Red

Refactor

Green

New Test

Fix CUT

(31)

Test-driven Development

● Never amend your code unless you have a failing

test.

● Unless the change is a refactoring.

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

(33)

Unit Testing and Mocks

● System testing done within a constrained real

system not live.

● Unit and integration testing needs to disconnect

(34)

A short

Monty Python

moment…

(35)

(36)

(37)

(38)

Testing

(39)

Version Control

(40)

(41)