Essentials of Testing One tool, one purpose Bettina Polasek, Head of Quality Management Marco Cicolini, Head of Quality Engineering AdNovum Informatik AG ID 158
Agenda > Scope > Motivation > Toolbox > Tools for a Purpose > Demo > Experiences > Outlook > Conclusion 2 2
Quality Management 3 3
Scope Tools Quality Management People Process Organization 4 4
Motivation Issues - Many tools to chose from - Various advantages and disadvantages - Overlapping functionality Challenges - Finding the right tools for specific purposes - Selecting a small, but complete set of tools - Keeping the toolbox up-to-date 5
Selection Criteria Technology Methodology - Java - Static - .NET - Functional - JavaFX - Load, performance - … - Usability - Maintainability Layers - … - Web - Business - Persistence 6
Possible Toolbox 7 7
Our Toolbox 8 8
Technology Management Strategic - e.g. JEE applications Tactical - e.g. JUnit Operative - e.g. JUnit version 4.7 9 9
Which Tool for which Project? 10 10
How much Testing Is Enough? 11 11
Demo – Application Overview 12
Demo – Test Overview 13 13
Demo Recap – GUI Tests > General > General – Test whole application – Slow – Test use cases – Fragile > Selenium > Selenium – Real browser tests – Browser fragility – Ajax support > HtmlUnit > HtmlUnit – Faster than Selenium – Browser implementation – Request-based Test 14
Demo Recap – Database Tests > General > General – Stable (no UI involved) – No UI tests possible – Faster than UI tests – Database required > Embedded container > Embedded container – Test target container – Container specific – Slow > JPA > JPA – Fast – No EJB interaction – Test precisely what you want – Low-level API 15
Demo Recap – Business Tests > General > General – Very fast – No integration tests – Test only business logic > JUnit > JUnit – One test, one purpose – DB and UI not testable – Test only functionality > Mockito > Mockito – Mock “ away ” complex components – Mock setup may get complex – Test behavior – Mocking hides missing implementation 16
Experiences – General > Show your customer what you do. > Design simple and fast executable tests. > Decide on what and how you test (quadrants). > Have the right test distribution (testing pyramid). > Treat your test code as first class code! 17 17
Experiences – Tools > One tool, one purpose > Tools have to make testing simpler > Set up guidelines & documentation > Form experts for tools > Train developers in using tools 18 18
Outlook 19 19
Conclusion > A testing toolbox is a powerful tool to focus use of resources. – Maintenance and updates at a regular basis > Support an adequate tool for every purpose. – Focus on the test goal > Treat your test code as first class code. – Readability, maintainability 20 20
Resources > Books • xUnit Test Patterns (EAN: 9780131495050) • Pragmatic Unit Testing (EAN: 9780974514017 ) • Growing Object-Oriented Software, Guided By Tests (EAN: 9780321503626 ) • Test-Driven Development (EAN: 9780321146533 ) • Agile Testing (EAN: 9780321534460 ) > Tools • JUnit (www.junit.org) • Selenium (www.seleniumhq.org) • Mockito (www.mockito.org) • HtmlUnit (htmlunit.sourceforge.net) GlassFish (glassfish.dev.java.net) • 21 21
Questions? ? Visit the AdNovum booth! 22 22
Bettina Polasek bettina.polasek@adnovum.ch Marco Cicolini marco.cicolini@adnovum.ch AdNovum Informatik AG www.adnovum.ch
Additional Slides 24 24
Quality Manager Role 25 25 25
Demo Recap – GUI Tests General Test whole application Slow Test use cases Fragile Selenium HtmlUnit Real browser tests Browser fragility Faster than Selenium Browser implementation Ajax support Request-based tests 26
Demo Recap – Database Tests Tool Advantages Disadvantages General Stable (no UI involved) No UI test possible Faster than UI tests Database required Embedded container Test in target container Container-specific Slow JPA Fast No EJB interaction Test precisely what you want Low-level API 27
Demo Recap – Business Tests General Very fast No integration tests Test only business logic JUnit One test, one purpose DB and UI not testable Test only functionality Mockito Mock “ away ” complex Mock setup may get complex components Test behavior Mocking hides missing implementation 28
Experiences – Methodologies > Introduce people responsible for testing > Writing tests is more than just validating features > TDD / BDD > Review your tests 29 29
Recommend
More recommend
