The Basics of Unit Testing - Марія Шклярук

Transcript

1. The Basics of Unit Testing Mariia Shkliaruk
2. Agenda 1. What is Unit Testing? 2. Typical Excuses Of Not Writing Unit Tests 3. Best Practices for Unit Testing 1
3. What is Unit Testing?
4. Definition A unit test is a piece of code (usually a method) that invokes another piece of code and checks the correctness of some assumptions afterward. If the assumptions turn out to be wrong, the unit test has failed. 2
5. Unit Test Phases 3 unit test phases: • Arrange: initializing a small piece of code you want to test (also known as the system under test, or SUT) • Act: making some action with system under test (usually it’s a method calling) • Assert: checking the results 3
6. A Simple Unit Test Example [TestClass] public class SimpleParserTests { [TestMethod] public void ParseTest() { // Arrange var parser = new SimpleParser(); // Act var result = parser.Parse("123"); // Assert Assert.AreEqual(result, 123); } } 4
7. What Unit Testing is Not • Integration Testing • System Testing • Acceptance Testing (aka Functional Testing) 5
8. What Unit Testing is Not 6
9. Typical Excuses Of Not Writing Unit Tests
10. Typical Excuses Of Not Writing Unit Tests • ”I don’t have enough time for writing tests.” • ”Testing in monotonous and boring.” • ”I’m not a tester!” • ”I don’t know how to test it.” • ”But it works! It doesn’t need tests.” 7
11. I don’t have enough time for writing tests 8
12. Testing is monotonous and boring • Many books about unit testing are not very interesting and explain only theory • But errors prediction and prevention are very responsible activities • Not every developer is able to testing own (and someone else’s) code • ! It’s a valuable skill • Endless debug is more boring than writing tests 9
13. I’m not a tester! 10
14. I don’t know how to test it • But how have you written this code? • And how will you be using it? • Maybe there are some problems in project design (testable code often is better designed) 11
15. But it works! It doesn’t need tests • Imagine the perfect developer: • He have read all needed books • He knows all design patterns • He perfectly knows every line of code of his 515 classes • How do you think, after changing one line of code in one class can he accurately predict impact on the other 514 classes? • And what about not so perfect developers? • Maybe it’s more easier to use unit tests and don’t keep in mind extra details? 12
16. Best Practices for Unit Testing
17. Use Good Tools The tools should provide an ability: • Easy tests writing • Easy tests organizing • Easy tests running (all, some, one) • Quick feedback of pass/fail • Details on the fail conditions 13
18. What to Test - Testing Heuristics • Test at the boundaries • Test every error message • Test different configurations • Avoid redundant tests 14
19. What is a Mock Object? ”A mock object is an object created to stand in for an object that your code will be collaborating with. Your code can call methods on the mock object, which will deliver results as set up by your tests.” Source: ”JUnit in Action”, Vincent Massol 15
20. When to Use Mock Objects? • Real objects have non-deterministic behavior • Real objects are difficult to set up • Real objects have behavior that is difficult to cause • Real objects are slow 16
21. Properties of Good Unit Test • It should be automated and repeatable 17
22. Properties of Good Unit Test • It should be automated and repeatable • It should be easy to implement 17
23. Properties of Good Unit Test • It should be automated and repeatable • It should be easy to implement • Once it’s written, it should remain for future use 17
24. Properties of Good Unit Test • It should be automated and repeatable • It should be easy to implement • Once it’s written, it should remain for future use • Anyone should be able to run it 17
25. Properties of Good Unit Test • It should be automated and repeatable • It should be easy to implement • Once it’s written, it should remain for future use • Anyone should be able to run it • It should run at the push of a button 17
26. Properties of Good Unit Test • It should be automated and repeatable • It should be easy to implement • Once it’s written, it should remain for future use • Anyone should be able to run it • It should run at the push of a button • It should run quickly 17
27. Recommended Test Organization • Tests in a separate project/assembly • Ensure that tests are part of source control • Separate asserts from actions in test methods 18
28. Naming conventions Mapping tests to classes • One test class per class under test • Class: LoginManager • Test class: LoginManagerTests • One test class per feature • Class: LoginManager • Test classes: LoginManagerTests, LoginManagerTestsChangePassword 19
29. Naming conventions Mapping tests to specific methods • One test method per method under test • Method: ChangePassword() • Test method: ChangePasswordTest() • One test method per method under test with concrete input values and expected behavior • Method: ChangePassword() • Test methods: ChangePassword_EmptyPassword_ReturnsError(), ChangePassword_InvalidPassword_ReturnsValidationError() 20
30. Questions? 20