TEST DRIVEN DEVELOPMENT

Transcription

1 PERSONAL SOFTWARE ENGINEERING PROJECT: TEST DRIVEN DEVELOPMENT Kirsi Männistö 60114V PSEA_Test_driven_development.rtf Page 1 of 1 RoadRunners

2 Change history Version Description Author Date 0.01 Document is written KM Changes according to mentors comments KM Document submitted to delivery phase IM1 KM Terminology and definition. Abbreviation TDD XP Definition Test Driven Development Extreme Programming PSEA_Test_driven_development.rtf Page 2 of 2 RoadRunners

3 TABLE OF CONTENTS CHANGE HISTORY...2 TERMINOLOGY AND DEFINITION INTRODUCTION TEST DRIVEN DEVELOPMENT TDD IN PRACTISE TDD BENEFITS TEST DRIVEN DEVELOPMENT IN ROADMAPPING TOOL PROJECT GOALS FOR TDD IN THIS PROJECT INTRODUCING TDD TO PROJECT GROUP MANAGING TDD PROCESS TOOLS FOR TDD JUNIT ASSERTS USING JUNIT IN ECLIPSE INITIALIZING JUNIT IN ECLIPSE CREATING NEW TESTS REFERENCES...11 APPENDIX PSEA_Test_driven_development.rtf Page 3 of 3 RoadRunners

4 1 Introduction Purpose of this document is to introduce project group to the test driven development. Document describes what test driven development means. Reason for this subject was the testing course T There was exercise where junit was used and I was interested in using junit in practice. Unfortunately I cannot participate implementing in this project but I now I have change to learn it better. I can use this experience in some other school project. 2 Test driven development Test driven development, also known as Test-first design, means that instead of doing first detailed design on paper, developer uses tests to guide design. TDD is part of the core practices in XP. 2.1 TDD in practise In TDD implementation is done in following order: 1. Developer starts implementation by writing a test that specifies a bit of functionality. Test is written so that it fails. 2. Developer writes code so little as possible to make test pass. 3. Developer does some refactoring to the code to ensure that it has simplest possible design and finishes writing the functionality. [2] These steps are repeated through whole implementation phase. Figure 1. Phases in TDD [1] There are some rules when working with TDD: Test everything that can possibly break, tests come first and all tests run at 100 % all the time as regression test. 2.2 TDD benefits Unit test writing afterward to the code is difficult and takes time. With TDD tests are written in advance. All tests are run every time new functionalities are added into the code. This ensures that anything new does not break the older functionality. Regression testing is done automatically. PSEA_Test_driven_development.rtf Page 4 of 4 RoadRunners

5 When tests are written first, developer can easily avoid extra dependencies and keep modules testable in isolation. 3 Test driven development in Roadmapping tool project Developers will take TDD as their implementation method in this project from the beginning of the implementation phase. 3.1 Goals for TDD in this project Because time in this project is limited and system-testing phase is not going to be very long, TDD will provide fully functional end product to the customer. 3.2 Introducing TDD to project group Introducing will be done with this document. Here is presented all necessary information to get started with TDD. Method is introduced also in next group meeting, which is hold before implementation has been started. 3.3 Managing TDD process As a project manager I do TDD process managing. I will take care of that every developer has fully understood the process and I will help in every way if needed. Test code is documented same way as actual code. Every developer fills form (Appendix 1) concerning his/hers module. Form includes classes of one module and their test classes. Form includes table, where are number of all test cases and number of all passed test cases. This table is used in project review as one of the metrics. PSEA_Test_driven_development.rtf Page 5 of 5 RoadRunners

6 Motivation for this practice is done by telling the entire project group how important is to have product, which is fully tested. When testing is done already in early phases also amount of defects in later phases is decreased. 3.4 Tools for TDD JUnit is used in this project as a testing tool. As environment there is Eclipse, like defined in Project plan [4]. 4 junit JUnit is a testing tool for java developer. It provides a framework for regression testing. It can be used in unit and module testing. Installation packet can be found in Version to be used is the newest available: junit Asserts JUnit verifies test with asserts. Following asserts are used in junit: assertequals(string msg, Object expexted, Object actual) - Compares two values for equality. The test passes if the values are equal. assertfalse(string msg, boolean b) - Evaluates a boolean expression. The test passes if the reference is not null. assertnotnull(string msg, Object a) - Compares an object reference to null. The test passes if the reference is not null. assertnotsame(string msg, Object a, Object b) - Compares two object references using the == operator. Test passes if both refer to different objects assertnull(string msg, Object a) - Compares an object reference to null. The test passes if the reference is null. The test passes if the reference is null. assertsame(string msg, Object a, Object b) - Compares two object references using the == operator. The test passes if both refer to the same object. asserttrue(string msg, boolean b) - Evaluates a boolean expression. The test passes if the expression is true. fail(string msg) - Causes the current test to fail PSEA_Test_driven_development.rtf Page 6 of 6 RoadRunners

7 First string in all asserts is message, which is shown in test results. Asserts can be found in junit.framework.assert. [3]. More information about using junit can be found in junit homepage [5]. 5 Using junit in Eclipse While Eclipse is decided to be development tool in this project, this document describes only how to use junit in Eclipse. 5.1 Initializing junit in Eclipse First of all junit has to be installed: junit3.8.1.zip is downloaded and zipped in computer. Next Eclipse is opened and new or existing project is opened. After this junit.jar has to be added in project java build path. This done in toolbar: Project-> properties. There Java Build Path and tab Libraries are selected as in Figure 2. External JARs are added by selecting Add External JARs. This opens file browser view from where junit.jar can be browsed and selected. Figure 2. junit.jar adding in project's Java build path. 5.2 Creating new tests Before implementing is started developer has already architecture design to be followed. This design will now be specified. Developer creates in project new class without any functionality. However some empty methods can be written in this phase. After this new test class is created as any other class: Either from toolbar File-> New-> Class. New test cases are created as follow: 1. In Java perspective view (the normal view, where implementation is done) right mouse button is clicked above class to be tested: New.. -> Other.. ->Java ->JUnit -> TestCase- >Next. 2. Test case's name is given and following check boxes are selected: public static void main(...) Add TestRunner statement for: text ui (this shows test results in Eclipse's console and developer can easily click to the failed assert and switch direct to the particular code line) setup() PSEA_Test_driven_development.rtf Page 7 of 7 RoadRunners

8 teardown(). 3. In next page there are shown project's available classes and their methods. One class is selected (or only those methods that are wanted to test) 4. Finish button creates empty test methods in selected test class. SetUp- method is for construction of testing environment, like creating instance of class to be tested. TearDown is for deleting those instances. These methods are called by junit Framework. Before running any tests, there has to be TestSuite class, which collects all test class and runs them. TestSuite class is created as test case, except instead of TestCase TestSuite is selected. After Next button pressing developer can choose name for test suite and test classes to be added from existing test class. Following check box should be selected: public static void main(...) Add TestRunner statement for: text ui (same as in test cases) Now project can be build and run. Test running is done by selecting toolbar ->Run ->Run... Project name should be correct, but if not, it can be browsed and selected. TestSuite's name is added in Main class-field. (Figure 3.) PSEA_Test_driven_development.rtf Page 8 of 8 RoadRunners

9 Figure 3. Running tests PSEA_Test_driven_development.rtf Page 9 of 9 RoadRunners

10 6 References [1] Scott W. Ambler. Test driven development [2] Object Mentor, Inc. Test driven development [3] Rusama Mikko. T76613 Lecture 6: Unit and functional testing with JUnit and HttpUnit /2003/material_protected/lecture6/lecture6.html [4] Roadrunners - Project plan. cvs: \\T \Roadmap\Doc\Management\T _Project_Plan.rtf. [5] junit homepage. PSEA_Test_driven_development.rtf Page 10 of 10 RoadRunners

11 Appendix 1. Class Description Test class Testcases ExampleClass This class is junit example class ExampleClassTest 5 Phase Module All test cases All passed test cases IM1 Example module IM2 Example module PSEA_Test_driven_development.rtf Page 11 of 11 RoadRunners