testing: python, java, groovy, etc
Post on 11-May-2015
1.127 Views
Preview:
DESCRIPTION
TRANSCRIPT
Copyright © 2012 Russel Winder 1
Testing: Python, Java, Groovy, etc.
Prof Russel Winder
http://www.russel.org.uk
email: russel@winder.org.ukxmpp: russel@winder.org.uk
twitter: @russel_winder
Copyright © 2012 Russel Winder 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 inthe hands of ignorant managers.
Copyright © 2012 Russel Winder 3
Structure
Introduction.
First part.
Short break.
Second part.
Conclusion.
Copyright © 2012 Russel Winder 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. appearingto get too long as interjections may get stackedto be unstacked at a break.
Copyright © 2012 Russel Winder 5
Introduction
Copyright © 2012 Russel Winder 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 7
Interstitial Advertisement
Copyright © 2012 Russel Winder 8
Projects
● Gant● GPars● SCons● GroovyFX● Groovy● Gradle
● GroovyBalls● GFontBrowser● Pi_Quadrature● Sleeping_Barber
OK, so it's all open source.
Copyright © 2012 Russel Winder 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).
eXtreme Programming
Copyright © 2012 Russel Winder 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 11
The Two Parts
Copyright © 2012 Russel Winder 12
The Terms
● Unit test.● Integration test.● System test.● Acceptance test.
Smoke test.
Mutation test.
Copyright © 2012 Russel Winder 13
Unit Test
● Test the functions and methods for correct behaviour.
May well require use of mocks.
Copyright © 2012 Russel Winder 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 15
System Test
● Test that the system as a whole works as expected.
Smoke test – a pre-test to ensure it isworth running all the tests.
No mocks at all.
Copyright © 2012 Russel Winder 16
Acceptance Test
● Test that the “purchaser” makes to be happy with the system as delivered.
Used to be crucial, now contracts are usuallynot for one-off items, but for annual support.
Copyright © 2012 Russel Winder 17
Code under Test
Copyright © 2012 Russel Winder 18
The Tools
● Test frameworks:● Unit testing● Integration testing● System testing.
Acceptance testing usually usesa different sort of tool, FitNessefor example.
http://fitnesse.org/
Programming languagespecific.
Copyright © 2012 Russel Winder 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 manyxUnit variants on the assumption it wasThe right thing to do…
…even when it wasn't.
Copyright © 2012 Russel Winder 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 21
In the Python-sphere
● PyUnit, aka unittest● py.test, aka PyTest● Nose, aka nose
There are many others but the aboveare the ones that matter.
Copyright © 2012 Russel Winder 22
In the JVM-sphere
● Java:● JUnit3● JUnit4● TestNG
● Scala● ScalaTest● ScalaCheck● Specs2
● Groovy● GroovyTestCase
– JUnit3 in disguise
● Spock
● Clojure● clojure.test● Midje● lazytest
Kotlin, Ceylon, Jython, JRuby,…
Copyright © 2012 Russel Winder 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 24
Individuals / Teams
● Single developer projects need no other tools.● Multi-developer projects need more infrastructure.
Copyright © 2012 Russel Winder 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 26
Developer
Developer
DeveloperDeveloper
Developer
Mainline Repository
Continuous Integration
Deployment Server
Team Workflow
Continuous deliveryContinuous deployment
System Test Server
Copyright © 2012 Russel Winder 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/
Copyright © 2012 Russel Winder 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 29
JetBrains TeamCity
● Commercial continuous integration server.● Free support for FOSS projects.● Cloudy.
http://gpars.codehaus.org/
http://www.jetbrains.com/
Copyright © 2012 Russel Winder 30
The Process
Red
Refactor
Green
New Test
Fix CUT
Copyright © 2012 Russel Winder 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 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 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 34
A shortMonty Python
moment…
Copyright © 2012 Russel Winder 35
Copyright © 2012 Russel Winder 36
A Short Coding Dojo
Copyright © 2012 Russel Winder 37
Conclusion
Copyright © 2012 Russel Winder 38
Testing
● It's what programmers do.
Copyright © 2012 Russel Winder 39
Version Control
● It's the way programmers work.
Copyright © 2012 Russel Winder 40
Interstitial Advertisement
Copyright © 2012 Russel Winder 41
Testing: Python, Java, Groovy, etc.
Prof Russel Winder
http://www.russel.org.uk
email: russel@winder.org.ukxmpp: russel@winder.org.uk
twitter: @russel_winder
top related