IT Event 2011 Spring

1. Code-driven testingАудиторія: розробникиОлександр Павлишак, 2011pavlyshak@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(); // Arrangeint result = math.Sum(1, 2); // ActAssert.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Виконання тестівОдного, декількох, всіхІнтеграція з IDEAPI для написання тестівАвтоматизаціяПерегляд результатів

9. Unit test frameworkNUnit, MS Test, MBUnit, DBUnitJUnit, JWalk, TestNG, DBUnitC++test, CppUnit, Google C++ Testing FxPyUnit

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Декілька stubsFakesStubs 0..*Mocks 0..1

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

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

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

20. Якості

21. Якості юніт тестівReadableMaintainableTrustworthy

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

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

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

26. Різновиди

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

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

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

30. Інтеграційні тести -- ОзнакиTearDown() DateTime.NowThreadEnvironment.MachineNameDatabase.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 patternsMocks/stubs/fakes, isolation frameworksTDD, Test Driven DevelopmentContracts, Contract Driven Development

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