1 / 46

Test - DRIVEN DEVELOPMENT

Test - DRIVEN DEVELOPMENT. Lecture 3. Definition. Test-driven development (development through testing) is a technique of programming, in which the unit tests for the program or its fragment are written before the program and, in essence, manage its development. Methodology :

dore
Télécharger la présentation

Test - DRIVEN DEVELOPMENT

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Test-DRIVEN DEVELOPMENT Lecture 3

  2. Definition • Test-driven development (development through testing) is a technique of programming, in which the unit tests for the program or its fragment are written before the program and, in essence, manage its development. • Methodology: • Write a new code only when automatic test doesn’t work. • Remove duplication

  3. Development cycle (briefly) • Red - write a short test that does not work and may not even compile. • Green- make test work as quickly as possible, do not think about the correctness of design and clean code. Write just enough code to make the test working. • Refactoring- delete any duplication from the written code. • Red- green - refactoring. • Refactoring is the process of full or partial conversion of the internal structure of the program while maintaining its external behavior.

  4. Development cycle (scheme)

  5. Development cycle • The programming system is extracted from the repository if it is in a consistent state, when the full set of unit tests run successfully. • Add a new test. It may consist of verifying whether the system implements a new behavior or contains some error, which is become known recently. • The full set of tests is performed successfully except a new test which fails. This step is necessary to verify the actual test - if it is included in the general system of testing and if it correctly reflects the new requirement to the system, which, of course, does not satisfy to yet. • The program will change to ensure that all tests run as quick as possible. You need to add the simplest solution that meets the new test, and at the same time do not spoil the existing tests. A large part of the undesirable side effects and remote effects from the changes is made at this stage, using a full set of tests.

  6. Development cycle (continuation) • The full set of tests runs successfully. • Now, when the required functionality is achieved in the simplest way, the program is refactored to improve the structure and eliminate redundant, duplicated code. • The full set of tests runs successfully. • The set of changes made in this cycle in tests and program is saved in the repository. Now again, the program is in a consistent state and contains a clear improvement over the previous state. The duration of each cycle is a few minutes.

  7. Example 1. Fibonacci Numbers • The Fibonacci sequence is determined by the following relation:F(n) = F(n - 1) + F(n - 2)F(1) = 1F(0) = 0 • You want to write a function to determine the n-thnumber of the sequence.

  8. Example 1 • The first test: • The implementation of function:

  9. Example 1

  10. Example 1 • Check the second number of the sequence

  11. Example 1

  12. Example 1 • Modify the function

  13. Example 1

  14. Example 1 • Add new test, checking the 3rd and the 4th numbers of the sequence:

  15. Example 1

  16. Example 1 • Modify the function

  17. Example 1

  18. Example 2. Function CombinePaths • We want to implement the function of addition two given path. • C:\Data\+MySQL\data.sql=C:\Data\MySQL\data.sql • Consider the following cases: • Different variations of the presence/absence of the final and the beginning slash in the first and second path:C:\folder + file.txtC:\folder + \file.txtC:\folder\ + file.txtC:\folder\ + \file.txt • If the first path is empty:" + file.txt • If the second path is absolute:C:\folder + D:\folder2\file.txt

  19. Example 2 • First test

  20. Example 2 • Implementation of the function:

  21. Example 2

  22. Example 2 • Modify the function:

  23. Example 2

  24. Example 2

  25. Example 2

  26. Example 2 • Modify function:

  27. Example 2

  28. Example 2

  29. Example 2

  30. Example 2 • Modify the function:

  31. Example 2

  32. Example 2 • Finally the function looks like:

  33. Techniques of TDD • Isolated Test • Test List • Assertion First • Test Data • Evident Data

  34. Isolated Test • If you do not pass one test, others should not fall. • If the tests are isolated, the order of their running does not matter. • Tests should not use general resources. General resources used by the tests should not be changed during the test.

  35. Test List • Write down all the tests you want to implement and adhere to this list. • After the green line you must always add one test, so do not just programming all tests at once. • Tests in which there is a need in the process of writing another test, must be simply entered in the test list.

  36. Assertion First • This approach allows you to instantly answer two important questions: “What is the correct result of the test?” and “How I can confirm that it is correct?”. • Firstly we define what do we want to get and then we create the necessary conditions to pass the test (assert). • We should not have too much claims in a test (perfect ─ one, maximum ─ three).

  37. Test Data • Do not use the same data. • If there is no difference between 1 and 2, get 1. • If three test sets will give you the same result as 10 test sets, use three. • Use realistic test data.

  38. Evident Data • It should be obvious where is this or that result from. • Do not hide the calculation of the constants, so it will be clear what needs to be programmed. • Test code should be read from the first time.

  39. Evident Data • Or more evident data:

  40. Tools for unit testing • Java: JUnit; • C++: CppUnit, Boost Test; • Delphi: DUnit; • PHP: PHPUnit; • С#: NUnit. • The full list of tools is here: http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks

  41. Terminology • Test method is a method that checks the behaviourof your object. • Assertion is a comparison of expected and actual results. • Method fixture is a set of operations performed before and after each test method. • Class fixture is a set of operations performed before and after all test methods in the class.

  42. The order of calling

  43. NUnit • NUnit - an open environment unit-test applications for .NET (including the platform Mono). • It was ported from the java language and written in J#. • The new version is written in C# with such innovations as attributes.

  44. NUnit • For the organization of tests the following attributes are used: • [Test] marks the test method. • [TestFixture] marks the class with a set of tests. • [SetUp], [TearDown] mark any procedure without parameters such as fixture level method.

  45. NUnit • The class “Assert” contains static methods of verification of actual values with the expected: • AreEqual, AreNotEqual. • AreSame, AreNotSame. • IsTrue, IsFalse. • Greater, GreaterOrEqual, • IsNotNull, IsNull.

  46. NUnit

More Related