Loading presentation...

Present Remotely

Send the link below via email or IM


Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.


Automated Testing: The Developers Viewpoint

SBB Developer Day 2010

Jonas Bandi

on 8 February 2011

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Automated Testing: The Developers Viewpoint

Traditional Developer Testing Java EE Testing Test Automation Pyramid Agile Development Traditional Testing:
Quality Assurance Embedded Containers Quality Assurance vs. Quality Control Unfortunately, in the software industry, all too many teams don’t realise their process doesn’t work until the testers find all the ways in which the product doesn’t work…
- Antony Marcano Testing can be more! Outside-In
Development Detecting Bugs Open-Source Tools “Nothing makes a system more flexible than a comprehensive suite of tests! Far above good architecture and good design!”
- Robert C. Martin Preventing
Bugs Supporting
Development Living Documentation Back in the 90’s there was an earlier wave of interest in programmer testing, it was primarily top down driven by managers who were afraid that the software industry would be destroyed by Japanese manufacturing techniques, the way that the auto industry had.
So they decided that since the Japanese had people check at the point of production rather than at the end of the line, we would do that too and so the obvious thing to do was have the programmers do it. A unit test that takes 1/10 of a second to run is a slow unit test (M. Feathers)

-> 3’000 classes each 10 tests -> 50 min What we want to do is blur the lines between testing and development. We want to get close to continuous testing. Short feedback cycles are the key. Coding and testing are part of one integrated process of delivering software. Iterative
Cross-functional teams

Definition of Done: Testing has to happen in the iteration!

Scrum: 1995
Agile manifesto: 2001

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan End of last century: Some people realized that the Waterfall does not work.

They came up with a new approach to development.
It gained a lot of momentum in the last 10 years. Polyglot Testing Web UI-Testing JBoss Embedded, Glassfish Embedded, Open EJB
Arquillian Consider writing (some of) your tests in another language:
Ruby / JRuby, Groovy Maven integration
EJB, CDI, JPA, JMS support
Supporting many containers
Supporting JUnit, TestNG
Supporting in-container, as-client Dynamic languages are very powerful for testing
Testing is even more important in DL
Traditionally used by agile communities
Powerful expressive capabilities of the languages -> internal DSLs (web, sql, rest/soap) For Java they are a very intersting option for functional and integration testing
Anyway separated solutions
Profit from their strenghts
Relative easy integration (JVM based, Tool support) Embedded Databases Java has a very rich open-source ecosystem.
Tools and libraries for virtually every problem
Testability is usually a big concern in OS In-Container vs.
Out-of-Container There are many embedded databases: SqlLite, HSQLDB, Derby (JavaDB), H2
Do you really need Oracle (for your tests)?
Can you architect your system in a way that it is not dependent on the specific DBMS? Minimal alternative: Local Database Embedded databases run inside you Unit-Test
Very fast
No external dependency
Fixture data specific for each test The problem with the DB is, that it is often the input and the output for your test.
You can mock the DB but this makes the test less relevant (and is a lot of work).

You dont want dependencies outside of your project.
Ideally: Checkout - Build - Run Tests

Better for new developers, distributed development, continuous integration ...

No dependency on the specific DBMS:
Good design strategy,
Especially now: Vendor lock-in, Cloud

There are tons of scaling applications that use mysql! Source -> the polyglott programmer

There is often fear of another language.
Think of it: You are using already a lot of languages in your project (java, sql, xml, html, ui, test-scripts)

Ruby is popular among agile testing teams.

It is a good practice to write your unit tests in the same language as the programm code. Selenium
Canoo WebTest
WebDriver / Selenium 2.0 Driver Concepts:
Browser emulation
Browser automation Always start with observable business value!
Ensure development always is focused on: Satisfying stakeholder needs
Software that matters
Usable software Antipattern: Start with database, expose all data, without knowing what it will be used for
We will care about that later… we don´t know it yet … lets be future proof
Violates good design principles Encapsulation and Abstraction. „Tell don´t Ask“.
Our systems get heavily coupled. Spaghetti. Big ball of Mud. Monolitic.

Start with the Story -> Agile Development Style

Not to be confused with top-down development:
Top-Down -> Starting from diagrams, code artifacts are the last step
Outside-In -> Always code artifacts, driving the system from the artifacts that are exposed to those on the inside of the system Problems with Unit-Testing Not reflecting quality of the whole system
Keeping them small and decoupled
Keeping them fast
Tests have bugs
You can't test what is missing Testing Quadrants from Agile Testing by Crispin/Gregory Agile development also changes how testers and developers interact and what their role is in the process.

Testers and developers should interact intesely.
They should feel as part of the same team with the same goals and not working against each other.

eg: Queen of spades -> story

They should all be part of the sprint commitment.

It also reflects in the types of tests. by Mike Cohn Running an Agile project without automation is like walking the tight-rope without a safety net, except the tight-rope is on fire, someone is strumming it like a banjo, and you’re wearing two left shoes.
- John Sonmez Automation is a necessity! Each iteration has to be tested completely!
Incremental development: you change things from earlier iterations.
Regression testing becomes crucial!
You would need an army of manual testers and even then feedback would not be quick enough!
Bugs must be found during iteration not at the end! Executable Specifications TODO: Fitness Example Books Unit-Testing "Fail early to succeed sooner!" Quick Feedback
Safety-net when doing changes
Divide & Conquer Why do we write tests? Ensure the system works correctly
Achieve sign-off
Protect against regression
Refactor confidently
Achieve a good design
Drive the development
Definition of Done
Increase customer interaction
Document the system Developer Testing is Overrated! Source: Code Complete - Steve McConnell Testing is overrated - http://railspikes.com/2008/7/11/testing-is-overrated Who does what?

Why do we developer focus so much on unit-tests?
Because its the thing we know ho to do?
We can do it without changing the process too much. Does it still need testers? -> Yes!
Crossfunctional Teams does not mean there are no testers!
Debate: Testing vs. Checking
Automation allows Testers to do valuable work. Automated Testing:
The Developers Viewpoint About Me: The audience? Who is a developer?
Who is a tester?
Who is practising agile Development?
Who is practising TDD? TechTalk is a software development and consulting company with ~60 people located in Vienna, Budapest and Zürich. Agile Development and Testing is one of our Focus. Jonas Bandi
Twitter: @jbandi enthusiastic IT professional
working for TechTalk Questions? Comments? Where Errors are introducd into Software: Which deployed features are actually used: Test Driven
(TDD) Acceptance Test
Driven Development
(ATDD) Specification By Example Equivalence Hypothesis “As formality increases, tests and requirements become indistinguishable. At the limit, tests and requirements are equivalent.”
- Equivalence hypothesis,
Martin & Melnik Executable test-based specifications Abstract requirements and specifications are not a good tool for communication.
Concrete examples are much better.
Usually examples are not formalized and not shared. Testing is a gate at the end. No interaction before. Completely separated from the development phases.

This is a one-way process.
Feedback is not part of the process!
Going back is considered as a failure!

Based on the the theory of the exponential cost of change.
However this is a self-fulfilling prophecy...

Who has a QA department? What do they do? External vs. Internal Quality:
Inner Circle: Tests are concerned with code quality (are we doing it right?)
Outer Circle: Test are concerned with the system quality (are we doing the right thing?) Who is doing TDD?
What is the benefit of doing TDD?

Most important benefits:
Positive influence on design
Tests can be used as a documentation of the unit
Regression testing

Insight: It is not (only) about testing. It its about what our classes should do.
• Insight: Misunderstandings in requirements are not catched by unit-tests.
• Wouldn't it be great it we could extend this to the whole system?
• Goal: Automated tests to confirm features. Paper published for IEEE 2008, Robert C. Martin and Grigori Melnik

Requirements == Tests
Traditionally this is not recognized because RE and Testing are set up as different disciplines
But they are about the same: how the system is used
Wouldn’t it make sense to leverage some synergies? Behavior Driven
(BDD) BDD / Acceptance Testing Cucumber / cuke4duke This animated Prezi is available online: http://bit.ly/eFlN2g
Full transcript