Test Driven Development. Software Engineering, DVGC18 Faculty of Economic Sciences, Communication and IT Tobias Pulls and Eivind Nordby

Size: px

Start display at page:

Download "Test Driven Development. Software Engineering, DVGC18 Faculty of Economic Sciences, Communication and IT Tobias Pulls and Eivind Nordby"

Linda Lee
6 years ago
Views:

1 Test Driven Development Faculty of Economic Sciences, Communication and IT Tobias Pulls and

2 Principle Use Executable Specifications Test Driven Development (TDD) xunit Behaviour Driven Development (BDD) RSpec Automatic Acceptance Tests FIT, Selenium, Sahi, Watir, FITnesse

3 TDD in practice: test syntax Create a Test project OR Import library using Microsoft.VisualStudio.TestTools.UnitT esting; Informative name for namespace Declaration that class is test related TestClass is the common keyword to use. See documentation of MsTest for other options Methods should be public void and take no parameters Namespace XXXTest { [TestClass] public class TestXXX_X { [TestMethod] public void A_A_A() { } } }

4 TDD in practice: test syntax, example Code to test that creation of a Set is possible [TestMethod] public void Existance() { Set s = new Set(); Assert.IsNotNull(s); }

5 TDD in practice: test syntax, example Code to test insert-method in a class reprenting a Set [TestMethod] public void Insert() { Set s = new Set(); int anelement = 5; s.insert(anelement); Assert.IsTrue(s.Contains(anElement)); }

Dojo info Karate or MA Dojo is training room Everyone takes turns trying out techniques One produces test cases Supplier would be the aggressor in karate

6 Dojo info Karate or MA Dojo is training room Everyone takes turns trying out techniques One produces test cases Supplier would be the aggressor in karate Other codes to make test cases pass Receiver would be the defender in karate Kata Practice state of the art techniques Teacher shows Student repeats same procedure

7 TDD Kata: A Stack Implement a Stack class using TDD Demonstration by teacher Implement a List class using TDD Done by students Iterate between teacher and students Teaches does one small feature for the stack, students do the same feature for the list as a kata Two students per computer Repeat for a while Some features first day, continued second day

8 Value of Testing vs Specification Testing Testing is by samples Testing can only prove a system to be wrong Test cases may be executed Specification Specification describes general case Specification describes what is right Specifications may often be executed Imperfect tests, run frequently, are much better than perfect tests that are never written at all

9 TDD vs Architecture and Design Coplien and Martin Debate TDD, CDD and Professionalism Bob Martin = Robert C. Martin (Uncle Bob) Jim Coplien = James Coplien

10 Testing vs. xdd Traditional Unit, Integration, System and Acceptance Testing are done after the fact Code, then write test Ideally, system and acceptance tests are written before design and coding xdd (TDD, BDD) tests are written before design and implementation They are driving the development Also called Example Driven Development No development is done unless there is a failing test TDD tests are As much about exploring the design of the system As they are about bug catching TDD is how I do it, not what I do

11 Tim Ottingers TDD in Three Index Cards Three Index Cards To Easily Remember The Essence Of Test-Driven Development Card #1. Uncle Bob s Three Laws Fail first, Only enough test to fail, Only enough solution to pass Card #2: FIRST Principles Fast, Isolated, Repeatable, Self-verifying, Timely Card #3: Core of TDD Red, Green, Refactor

12 Uncle Bob s Three Laws of TDD 1. Do not write a line of production code until you have written a failing unit test No production code can be written until there is a failing unit test 2. Do not write more of a unit test than is sufficient to fail, and not compiling is failing So you cannot write very much of the unit test before you write production code 3. Do not write more production code than is sufficient to pass the test You cannot write a little bit of unit test and then run off and write production code. These three laws lock you into a cycle that is perhaps 30 seconds long You are actually writing unit tests and production code concurrently, with the tests perhaps 30 seconds to a minute ahead That is my definition of TDD

13 FIRST Principles F ast Mind-numbingly fast, as in hundreds or thousands per second. I solated The test isolates a fault clearly. R epeatable I can run it repeatedly and it will pass or fail the same way each time. S elf-verifying The Test is unambiguously pass-fail. T imely Produced in lockstep with tiny code changes.

14 Red/Green/Refactor Start Write a test for new capability Refactor as needed (*) Compile Run the test And see it pass Fix compile errors Write the code (*) Always on a green solution Run the test And see it fail

15 TDD Pattern: Red, Green, Refactor Test Driven Development: By Example, Kent Beck, Addison-Wesley Longman, 2002 Simple example: Push for stack Create test case: testpush Compile error: no such method exists Create push method (stub) No compile error, but test case does not pass Implement push to satisfy test Test passes Refactor (if needed) Always refactor on a fully working (green) system

16 TDD Pattern: Arrange, Act, Assert Arrange import junit.framework.*; public void TestClass extends TestCase { public void testsomething() { Stack stack = new Stack(); stack.push("test string"); Act String result = stack.pop().tostring(); Assert assertequals("expected last value pushed", "Test string", result); } }

17 Unit Testing vs Integration Testing A test is not a unit test if 1. It talks to the database 2. It communicates across the network 3. It touches the file system 4. It can't run correctly at the same time as any of your other unit tests 5. You have to do special things to your environment (such as editing config files) to run it It is an integration test

18 Acceptance Testing Requirement documents become outdated And frequently not updated Executable specifications are always accurate Are actually executed

19 Frameworks for Automatic Acceptance Testing Fit Executes HTML tables with matching input and output FitNesse Front-end to Fit and wiki to organize tests RSpec (for Ruby) Write tests in plain english JSpec RSpec for Java All do Specification by Examples

20 Working with Acceptance Testing End user / product owner specify examples Examples are encoded in framework Selected examples drive development top-down Normally complemented by unit tests bottom-up

Analysis of the Test Driven Development by Example

Analysis of the Test Driven Development by Example Computer Science and Applications 1 (2013) 5-13 Aleksandar Bulajic and Radoslav Stojic The Faculty of Information Technology, Metropolitan University, Belgrade, 11000, Serbia Received: June 18, 2013 /