IT Event 2011 Spring

1. Code-driven testing Аудиторія: розробники Олександр Павлишак, 2011 pavlyshak@gmail.com

2. Agenda Поняття Unit test Підміна залежностей, stubs Тестування взаємодій, mocks Якості хороших тестів Unit vs integration testing Практики Метрики

3. Тестування Починається разом із розробкою Запускаємо і дивимось Створюємо допоміжні засоби Консольні програми Допоміжний UI

4. Unit test, визначення Код (зазвичай, метод) Який викликає інший код І після цього перевіряє правильність Деяких припущень Unit = модуль, компонент (функція, метод, клас, Unit of Work)

5. Unit test [TestFixture] publicclassCalculatorTests { [Test] publicvoidSum_ReturnsCorrectValue() { var math = newCalculator(); int result = math.Sum(1, 2); Assert.AreEqual(3, result); } }

6. Arrange/Act/Assert [TestFixture] publicclassCalculatorTests { [Test] publicvoidSum_ReturnsCorrectValue() { var math = newCalculator(); // Arrange int result = math.Sum(1, 2); // Act Assert.AreEqual(3, result); // Assert } }

7. Єдиний assert/єдиний verify Юніт-тест повинен тестувати щось одне Назва тестуважлива [Test] publicvoidStart_Test() { var survey = newSurvey(); survey.Start(); Assert.AreEqual(SurveyState.InProgress, survey.State); Assert.IsTrue(survey.FinishDate > survey.StartDate); }

8. Unit test framework Виконання тестів Одного, декількох, всіх Інтеграція з IDE API для написання тестів Автоматизація Перегляд результатів

9. Unit test framework NUnit, MS Test, MBUnit, DBUnit JUnit, JWalk, TestNG, DBUnit C++test, CppUnit, Google C++ Testing Fx PyUnit

10. Continuous integration

11. Continuous integration

12. Залежності

13. DEMO [Test] publicvoidStart_ChangesStateToInProgress() { var survey = newSurvey(); survey.Start(); Assert.AreEqual(SurveyState.InProgress, survey.State); }

14. Залежності Survey залежить від EmailSender Не хочемо відсилати справжні листи Створюємо stub вручну Створюємо stub автоматично Все ще тестуємо стан!Assert.AreEqual(SurveyState.InProgress, survey.State);

15. Interaction testing Потреба тестувати взаємодії Створюємо mock вручну Створюємо mock автоматично Один mock на тест Тестуємо не стан, а взаємодію!mockEmailSender.Verify();

16. Stubs + mocks Один тест – один mock Декілька stubs Fakes Stubs 0..* Mocks 0..1

17. Короткий підсумок

18. How unit testing helps Швидший цикл тестування коду Коротший фідбек про можливі дефекти Дефекти дешевші

19. Плюси тестів Кращий код Стабільніша нова функціональність Більше впевненості у змінах Менше регресій Коротші цикли релізів

20. Якості

21. Якості юніт тестів Readable Maintainable Trustworthy

22. Readable Легко зрозуміти, що відбувається в тесті Який код тестується Які передумови Які припущення перевіряються Що тестує тест Простий код тесту

23. Trustworthy Релевантні до помилок Стабільно (не) проходять Немає конфліктуючих тестів Справді тестують

25. Maintainable Тести легко реагують на зміни Не вимагають конфігурації Не залежать від інших тестів Простий код тесту

26. Різновиди

27. Види тестів Юніт Інтеграційні Інші

28. Юніт тести Тестують один модуль Виконуються виключно в пам’яті Не вимагають конфігурації Не вимагають DB, FS, AD, Net Завжди Повторювано проходять Або повторювано не проходять Тому що не залежать від змінних факторів

29. Інтеграційні тести Тестують модулі разом Можуть мати різну поведінку В залежності від Середовища (FS, DB, AD, OS, .config) Порядку виконання Кількості виконання Багатопоточності Повного місяця

30. Інтеграційні тести -- Ознаки TearDown() DateTime.Now Thread Environment.MachineName Database.Save(…) File.Open(…)

31. Mixing Чітке розділення UT та IT

32. Trustworthy Юніт-тести – ДОВІРА Проходять --> мабуть немає дефекту Не проходять --> точно є дефект Інтеграційні тести – (деколи) НЕДОВІРА Проходять --> немає дефекту Не проходять --> можливо дефект

33. Практики

34. Логіка в юніт-тестах Asserts in if/switch/for/while Значно підвищується ймовірність появи дефекта в тесті Погіршується readability & maintainability

35. Дублювання логіки production коду Приклад Tests last Тест не тестує Expected hardcoded values

36. Magic numbers Приклад Найпростіші можливі значення Оголошення і перевірка в тесті

37. Tests first Тест Не компілюється/не проходить Реалізація Тест проходить Покращення Впевненість, що тести не містять баги

38. Зміна тестів Створення: У більшості випадків Видалення: Коли тест більше не потрібний Редагування: Для maintainability/readability Для швидкості Коли тест повинен виконуватись по-іншому

39. Тестувальник знаходить дефект Новий тест Не повинен бути знайдений тестувальниками знову

40. Що міряти Кількість регресій Час виправлення дефектів Метрики якості коду People feedback Покриття (coverage)

41. Покриття (test coverage)

42. Покриття – способи перевірки «Диверсія» в продакшн коді Автоматизовані засоби

43. Branch coverage

44. Покриття Не завжди працює 0% 1-2% ~50% >95%

45. Обирайте усвідомлено Тестування не безкоштовне Надмірність тестів Надмірність тестів взаємодій 100% покриття не завжди потрібне

46. На що дивитись далі Unit testing patterns Mocks/stubs/fakes, isolation frameworks TDD, Test Driven Development Contracts, Contract Driven Development

47. Q&A Code-driven testing Олександр Павлишак, 2011 pavlyshak@gmail.com