• Save
Test driven development v1.0
Upcoming SlideShare
Loading in...5
×
 

Test driven development v1.0

on

  • 1,152 views

Test Driven Development best practices captured in these slides. Code samples are in Java.

Test Driven Development best practices captured in these slides. Code samples are in Java.

Statistics

Views

Total Views
1,152
Views on SlideShare
1,152
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Test driven development v1.0 Test driven development v1.0 Presentation Transcript

  • Test Driven Development Best Practices Ganesh Kondal Principal Architect May 21, 2013
  • 1. Overview and Introduction 2. TDD – What is it & Process 3. TDD Challenges 4. TDD Learning / Best Practices 5. TDD Frameworks & Variations 6. Q & A Agenda
  • Overview and Introduction View slide
  • • TDD is the most misunderstood practice in Agile / Xtreme programming. • Best practices starts with clearing the notion of what exactly is TDD. • Needs a mindset change at all levels • People • Processes - Continuous Delivery • Coding practices. • TDD is not just to find defects – but to give feedback on – quality of the implementation (“Does it work”) and design (“Is it well structured?”) Overview and Introduction View slide
  • TDD – What is it & Process
  • • Golden Rule - “ Write a failing unit test. “ • Why so? You don’t have any code to satisfy it • Focusses on what needs to be done. “intent” • Process of TDD • The Bigger Picture • Begins each feature with a failed acceptance tests • Avoid starting with unit tests for classes [ testing boundary errors, wrong boolean expressions etc.,] What is it & TDD Process • First, build a “walking-skeleton” • Implementation of the thinnest possible slice of real functionality that we can automatically build, deploy, and test end-to-end • End-to-end testing at the start, for better/working system design • Expose Uncertainty early – flush issues when there is time / goodwill / budget
  • • Acceptance Tests are to • Look from user point of view, before the implementers [class level tests] • Teams’ progress are seen as acceptance tests turn – red to green. • Different JUnit test suites (one for acceptance, one for regression) • Writing Tests – is a “design work” in TDD • Mock vs. stub - • Objects pre-programmed with expectations which form a specification of the calls they are expected to receive. • Stubs provide canned answers to calls made during the test What is it & TDD Process
  • TDD Challenges
  • •People are resistant to change. •People don’t know about TDD. •It will take too long to learn how to do TDD correctly. •We don’t know where to start; We can’t test our codebase. People •TDD takes a lot of practice, than it really is. •TDD takes way more time, without giving any real benefit.Perception •Adopting TDD for legacy applications. •Writing / maintaining tests takes time and effort. •Maintaining the test speed is vital. Slow tests demotivates test execution. •Needs constant care : else tests become brittle and fail. •User interfaces, real-time, and embedded software don’t lend themselves as naturally to TDD. •Setting up back-end components and precisely controlling their state inside automated tests requires care. •Unit testing concurrency. Technology TDD Challenges
  • TDD Learning / Best Practices to Sustain - Technology - People & Process
  • •Multiple runs of the test should consistently return true or consistently return false, provided no code changes were made.Consistent •Only two possible results: PASS or FAILAtomic •One test should be responsible for one scenario only. [Single responsibility principle]Isolation •Unit test must be easy to read and understandSelf Descriptive •Unit tests should not be interdependentIndependent •Should communicate the intent. •Unit tests are great design/usage ‘docs’)Communicative •Ensure the test setup and execution is easy and fast.Setup & Execution [Best] Practices to Sustain TDD – Technology
  • • Listen to tests • Bloated constructors – shows multiple responsibility; complicated design • Assign Defaults [Best] Practices to Sustain TDD – Technology cont.
  • [Best] Practices to Sustain TDD – Technology cont. • Test Readability • Tests are to test the features / capability – not blindly to test few lines of code (or an API per se.,) • Test names should describe features • No exception handling OR un-necessary assertions/fail(s) • assertFalse is better (readable than a ) assertTrue with ! • Name variables to show the role they play • Ensure test / source code are in different folders
  • [Best] Practices to Sustain TDD – Details contd., • Use ‘object mother’ to build complex test objects • Tests need to communicative – small, focused and well named • Let assertion failures be more meaningful • When using mock objects, always ensure, you check the expectations were met. • Make diagnostics clear – else while you refactor the code, you will not know –when a test fails for a wrong reason (than expected ways) • Precise Assertions, Expectations • Avoid asserting aspects that are not relevant. getCustomerById( customerID ) - ensure the customer has the ID passed; avoid checking the customers’ name for example. receiveAndProcessOrder(..) instead of processMessage(..)
  • [Best] Practices to Sustain TDD – People & Process • A ~3 week Induction program for each incoming associate • To cover aspects related to Test Driven Development, Libraries & Frameworks • Workshops to further ingrain the “Best Practices” • Govern the adoption of TDD – with code checks. • Ensure the team has understood the practices and tools correctly, and using them effectively. • Set simple goals. • Keep a check – to avoid (artificial) pressures to ship product soon. • Utilize TDD Tools, mocking frameworks, BDD/ATDD frameworks. • Ensure to get feedback, on usage, issues – as often as possible. • Monitor & Analyze impact at individual level & overall Project level – via metrics • Identify Gap Areas & address the same on a priority basis TDD Induction, KT & Workshops Governance Body Libraries & Frameworks Evaluation Model
  • TDD Frameworks & Variations
  • TDD Frameworks Category Name Description Suited For Unit test JUnit HttpUnit Simple Framework to write repeatable tests Instance of xUnit architecture JUnit 4.8.2 ships with Hamcrest HttpUnit – is a stalled project. DBUnit Junit extension Database is put into a known state before/after runs. JSFUnit JSFUnit is a test framework for JSF applications Allows complete integration testing and unit testing of JSF applications using a simplified API. Uses Arquillian [ Jboss Test Framework ] TestNG Similar to JUnit and NUnit Mocks Mockito / Jmock / EasyMock / Powermock Mocking frameworks Powermock is an extension of Mockito. Matcher Hamcrest Framework for writing matcher objects • UI validation; built to use with Junit 3, 4. • Jmock constraints are Hamcrest matchers. • Adaptors are available for easymock as well. TC Generator CodePro Eclipse plugin Static analyzer and Junit test code generator. Will be useful for jumpstarting legacy applications
  • TDD Frameworks Category Name Description Suited For UI Window licker Java GUI testing framework Swing, Dynamic HTML(Ajax) including GWT. Test Framework Shale Provides mock objects libraries JSF Servlet BDD JBehave Framework for BDD. Built on Java; very good documentation. Simple and fast. Supports story level testing. Suited for BDD / Java projects – easier for ones using Maven. BDD Cucumber Similar to jBehave. Built over Ruby. Cucumber-JVM is the java version. Supports feature level tests. Suited for BDD projects. Can use Selenium Web Drivers for UI feature testing aspects. Selenium For Browser automation Selenium Web Driver for automated Scripts Selenium IDE for quick record and replay tasks. Testing Platform Arquillian A test framework that can be used to perform testing inside a remote or embedded container, or deploy an archive to a container so the test can interact as a remote client; Under evaluation. From JBoss community
  • TDD Variations • ATDD • Criteria specified by the customer are automated into acceptance tests, which then drive the traditional TDD • BDD [Evans03] • Combines TDD Principles with ideas from domain-driven design to provide software developers and business analysts with shared tools and a shared process. • BDD revolves around • stories, that represent executable increment of business functionality. • Stories include one to many scenarios • Scenario represents a concrete behavior of the system
  • Q & A
  • Market Research on TDD Metric description IBM: Drivers Microsoft: Windows Microsoft : MSN Microsoft : VS Team Size 9 6 5-8 7 Team Location USA and Mexico Redmond, WA Redmond, WA Redmond, WA Experience Level > 10 Years 6 - 10 Years < 5 Years 0 3 6 0 5 1 1 7 0 5 0 2 Domain Expertise [Low (L), Medium (M), High (H)] M - L H M H Language Expertise [Low (L), Medium (M), High (H)] M - L H M H Programming Language Java C/C++ C++/C# C# Program Manager’s Experience [Low (L), Medium (M), High (H)] H H M M Team Location Distributed Collocated Collocated Collocated
  • TDD Benefits
  • TDD Benefits • TDD – is a design tool • Writing your test first makes you think of the software you are writing as a user of that software. • Drives the design and development to focus on what needs to be done – alone. • Eases Programmers life • Provides constant / instantaneous feedback / documentation at component level. • Proof your code works; fewer bugs & mainly ‘Peace of mind’ • Eases the ability to change • The software tends to be loosely coupled and easily maintainable, cause the developer is free to make design decisions and “Freedom to refactor without fear” • Regression safety net on bugs: • If a bug is found, the developer should create a test to reveal the bug and then modify the production code so that the bug goes away and all other tests still pass. • Always coding towards a goal to reach • Never write code than what is required! • Reduced defect density