We think you have liked this presentation. If you wish to download it, please recommend it to your friends in any social system. Share buttons are a little bit lower. Thank you!
Presentation is loading. Please wait.
Published byJessica Henderson
Modified about 1 year ago
Copyright © 2006 Korson-Consulting 1/219 Unit 4 Test First Development
Copyright © 2006 Korson-Consulting 2/219 Test First Many programmers have adopted this approach with near religious zeal “Test-first design is infectious! Developers swear by it. We have yet to meet a developer who abandons test-first design after giving it an honest trial.” Robert C. Martin
Copyright © 2006 Korson-Consulting 3/219 The Process Write a test that specifies a tiny bit of functionality Compile the test and watch it fail (you haven't built the functionality yet!) Write only the code necessary to make the test pass Refactor the code, ensuring that it has the simplest design possible for the functionality built to date Repeat
Copyright © 2006 Korson-Consulting 4/219 The Philosophy Tests come first Test everything All unit tests run at 100% all the time
Copyright © 2006 Korson-Consulting 5/219 Implications Code is written so that modules are testable in isolation. –Code written without tests in mind is often highly coupled, a big hint that you have a poor object-oriented design. If you have to write tests first, you'll devise ways of minimizing dependencies in your system in order to write your tests. The tests act as documentation. –They are the first client of your classes; they show how the developer intended for the class to be used. The system has automated tests by definition. –As your system grows, running full regression tests manually will ultimately take outrageous amounts of time. Measurable progress is paced. –Tiny units of functionality are specified in the tests. Tiny means seconds to a few minutes. The code base progresses forward at a relatively constant rate in terms of the functionality supported.
Copyright © 2006 Korson-Consulting 6/219 Problems – Unit Testing Specifications are hidden in the tests Tests should not be the only documentation –Pre and post conditions should be explicit Test first development should be combined with programming by contract
Copyright © 2006 Korson-Consulting 7/219 The Improved Process Design the interface for the component Write a test that specifies a tiny bit of functionality Compile the test and watch it fail (you haven't built the functionality yet!) Write only the code necessary to make the test pass Refactor the code, ensuring that it has the simplest design possible for the functionality built to date Repeat
Copyright © 2006 Korson-Consulting 8/219 Extensions Test driven development focuses on unit testing –Increments could be defined by system level test cases System level test cases, for an increment, should be created by the test team before code is written for that increment –Ideally these test cases would be approved by the stakeholders
Copyright © 2006 Korson-Consulting 9/219 Getting the Code Right vs. Getting the Right Code Test first development ensures the code is doing what the developer intended it to do Acceptance testing can now focus on determining how well the developer’s intent matches client’s expectations
Copyright © 2006 Korson-Consulting 10/ % All unit tests run at 100% all the time We can’t require the same for acceptance tests, because then we’d be back to big bang integration So the rule for acceptance tests becomes –No integration is complete unless 100% of the previously passing acceptance test continue to pass.
Copyright © 2006 Korson-Consulting 11/219 Problems – Acceptance Testing Specifications are hidden in the tests Tests should not be the only documentation –Stakeholders will typically require a textual or tabular format for reviewing acceptance tests –Extreme XPers will resist having documentation outside of the executable code.
Copyright © 2006 Korson-Consulting 12/219 Automating System Tests at the GUI Level Capture and playback tools don’t work well in a quasi-agile environment –The scripts they generate are not easily maintained Choose a tool that has an API and write automated tests that call the tools interface –This can be overly time consuming compared to the risks it addresses Create automated tests that operate just below the user interface –Sounds scary, doesn’t it
Copyright © 2005 Finetix LLC All Rights Reserved Test Driven Development and Mock Objects DevSession July Chris Donnan-
Acceptance Testing. What Is Acceptance Testing Customers write acceptance tests to determine if the system is doing the right things. Acceptance tests.
BEHAVIOR DRIVEN TEST DEVELOPMENT Specification by Example.
Unit-V -SOFTWARE QUALITY. To develop and deliver robust system, we need a high level of confidence that Each component will behave correctly Collective.
Acceptance and Unit Testing (introduction) Alessandro Marchetto Fondazione Bruno Kessler - IRST.
Testing Relational Database. Overview Once the design of a database system has been completed, the developers are ready to move into the implementation.
1 Note content copyright © 2004 Ian Sommerville. NU-specific content copyright © 2004 M. E. Kabay. All rights reserved. Rapid Software Development IS301.
Software Development QA Best Practices May 20, 2010 Suzette Hackl, CSM Senior Project Manager Skyline Technologies, Inc.
A Practical Guide To Unit Testing John E. Boal TestDrivenDeveloper.com.
Manage e-Project Information. Use of the Guide This guide sets out to provide a framework tool to assist e-Project information users. The object of the.
Extreme Programming ( an introduction ). Software Engineering Computer programming as an engineering profession rather than an art or a craft Meet expectations:
Ch-11 Project Execution and Termination. System Testing This involves two different phases with two different outputs First phase is system test planning.
Automated Testing with SilkTest: Strategies That Really Work Santa Clara Valley Software Quality Association September 14, 1999 Presented by John W. Green.
1 Test documentation and Test case design Iana Mourza QA Lead/Release Lead VMware, Inc
Chapter:4 Principles That Guide Practice Unit II.
Copyright © The OWASP Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the OWASP License. The OWASP.
Test Driven Development in PHP Jason E. Sweat
© University of Glamorgan1 Extreme Programming and its effect on project management Second Computing Project Management Workshop 13 September 02, University.
Planning, Organizing and Controlling. What is a project plan? A project plan is a model of the process that the project team intends to follow to realise.
Basic SDLC Models. Agenda SDLC definition Waterfall SDLC V-Shape SDLC Spiral SDLC RUP SDLC Agile methods.
1 GREY BOX TESTING Web Apps & Networking Session 10 Boris Grinberg
Converting Existing Cookbook Laboratory Experiments to Inquiry Format Wed-09:45-W-01 & Wed-01:00-W-09 Jeff Bigler
Introduction to Software Construction Chapter 1-3.
Lecture 8: Testing, Verification and Validation Dr Valentina Plekhanova University of Sunderland, UK.
9/4/20141 Iterative Project Management Chapter 2 – How Do Iterative Projects Function? Iterative Project Management / 01 - Iterative and Incremental Development.
Exploring Enterprise Agile Transformation Strategies Mike Cottmeyer, Enterprise Agile Coach LeadingAgile, LLC.
Brian Browning | Senior Director of Client Services Jason Arden | Director of Partner Engineering.
1 Note content copyright © 2004 Ian Sommerville. NU-specific content copyright © 2004 M. E. Kabay. All rights reserved. Configuration Management IS301.
Performance Testing Process Piotr Pawluk. Purpose. First thing you should do, is to define purpose of the tests, e.g.: Number of users will increase,
Chapter - 5 Understanding Requirements Unit II. Introduction Definition : “The broad spectrum of tasks and techniques that lead to an understanding of.
© 2016 SlidePlayer.com Inc. All rights reserved.