TDD Workshop UTN 2012
Upcoming SlideShare
Loading in...5
×
 

TDD Workshop UTN 2012

on

  • 249 views

This was a workshop given on the UTN University, for the Software Engineering students. The idea is to give a brief explanation about TDD, and how to use it.

This was a workshop given on the UTN University, for the Software Engineering students. The idea is to give a brief explanation about TDD, and how to use it.

Statistics

Views

Total Views
249
Views on SlideShare
249
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

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

TDD Workshop UTN 2012 TDD Workshop UTN 2012 Presentation Transcript

  • Test Driven Development Ing. Facundo Farias facundo.farias@gmail.com November, 2012
  • Agenda Introduction to Unit Testing.  Introduction to TDD.  How it works? Steps.  Mock Objects.  Dependency Injection  Characteristics  Benefits 
  • What is it?  Is an advanced technique of using automated unit tests to drive the design of software and force decoupling of dependencies.  Introduced by Kent Beck as part of XP (Extreme Programming).
  • What is a Unit Test?  In computer programming, unit testing is a method by which individual units of source code, sets of one or more computer program modules together with associated control data, usage procedures, and operating procedures, are tested to determine if they are fit for use.
  • What is a Unit Test? (Cont.) /// <summary> /// The sum should work using two integers. /// </summary> [TestMethod] public void SumShouldWorkUsingTwoIntegers() { // Given int numberA = 50; int numberB = 100; // When int sum = numberA + numberB; // Then Assert.AreEqual(sum, 150); }
  • How it works?
  • Steps (I)   Understand the requirements of the story, work item, or feature that you are working on. RED: Create a test and make it fail. ◦ Imagine how the new code should be called and write the test as if the code already existed. ◦ Create the new production code stub. Write just enough code so that it compiles. ◦ Run the test. It should fail.
  • Steps (II)  GREEN: Make the test pass by any means necessary. ◦ Write the production code to make the test pass. Keep it simple. ◦ If you've written the code so that the test passes as intended, you are finished. You do not have to write more code speculatively. Make this one test pass and continue. ◦ When the test passes, you might want to run all tests up to this point to build confidence that everything else is still working.
  • Steps (III)  REFACTOR: Change the code to remove duplication in your project and to improve the design while ensuring that all tests still pass. ◦ Remove duplication caused by the addition of the new functionality. ◦ Make design changes to improve the overall solution. ◦ After each refactoring, rerun all the tests to ensure that they all still pass.  Repeat the cycle. Each cycle should be very short, and a typical hour should contain many Red/Green/Refactor cycles.
  • Unit Testing Tools  Each programming language has different tools to use TDD: ◦ ◦ ◦ ◦ ◦ ◦ ◦ Junit, Mstest, Nunit, PHPUnit, Sunit, PyUnit, Unittest, CppUnit, CxxTest, Etc
  • Mock Objects   Mock Objects are simulated objects that mimic the behavior of real objects in controlled ways. A programmer typically creates a mock object to test the behavior of some other object, in much the same way that a car designer uses a crash test dummy to simulate the dynamic behavior of a human in vehicle impacts. Frameworks: Mockito, EasyMock, Jmockit, RhinoMocks, Nmock, etc.
  • Dependency Injection Dependency Injection is a software design pattern that allows a choice of component to be made at run-time rather than compile time. This can be used, for example, as a simple way to load plugins dynamically or to choose mock objects in test environments vs. real objects in production environments. This software design pattern injects the dependent element (object or value etc.) to the destination automatically by knowing the requirement of the destination.  Frameworks: Spring, Spring.net, Ninject, Unity, etc. 
  • Characteristics       Runs fast, runs fast, runs fast. If the tests are slow, they will not be run often. Separates or simulates environmental dependencies such as databases, file systems, networks, queues, and so on. Tests that exercise these will not run fast, and a failure does not give meaningful feedback about what the problem actually is. Is very limited in scope. If the test fails, it's obvious where to look for the problem. Use few Assert calls so that the offending code is obvious. It's important to only test one thing in a single test. Runs and passes in isolation. If the tests require special environmental setup or fail unexpectedly, then they are not good unit tests. Change them for simplicity and reliability. Tests should run and pass on any machine. The "works on my box" excuse doesn't work. Often uses stubs and mock objects. If the code being tested typically calls out to a database or file system, these dependencies must be simulated, or mocked. These dependencies will ordinarily be abstracted away by using interfaces. Clearly reveals its intention. Another developer can look at the test and understand what is expected of the production code.
  • Benefits  The suite of unit tests provides constant feedback that each component is still working.  The unit tests act as documentation that cannot go out-of-date, unlike separate documentation, which can and frequently does.  When the test passes and the production code is refactored to remove duplication, it is clear that the code is finished, and the developer can move on to a new test.  Test-driven development forces critical analysis and design because the developer cannot create the production code without truly understanding what the desired result should be and how to test it.  The software tends to be better designed, that is, loosely coupled and easily maintainable, because the developer is free to make design decisions and refactor at any time with confidence that the software is still working. This confidence is gained by running the tests. The need for a design pattern may emerge, and the code can be changed at that time.  The test suite acts as a 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. On each successive test run, all previous bug fixes are verified.
  • References         Test Driven Development: By Example [Kent Beck] Unit testing [Wikipedia] Guidelines for Test-Driven Development Using mock objects for complex unit tests Mocks Aren't Stubs [Martin Fowler] Dependency Injection [Martin Fowler] Spring for Java Spring for c#
  • Q&A