Theory and practice of unit tests

1. Unit тесты теория и практика Цуканов Павел ptsukanov@codereign.net

3. Unit Test инструменты

4. Изоляция в Unit тестах

5. От теории к практике

6. Вредные советы

7. Требования к тестам

9. Тест пишут программисты

11. Упрощение интеграции

12. Документирование кода

14. Тесты требуют много кодирования (тесты могут занимать от 50 до 80%).

15. Не всё можно проверить

16. Сам тест может содержать ошибки

18. Для создания тестов нужен framework. Наиболее часто используемые для .Net

19. Nunit (www.nunit.com)

20. xUnit ( xunit.codeplex.com)

21. Visual Studio Unit Test Framework

22. Интеграция со средой разработки.

23. ReSharper

24. TestDriven.net

25. Visual Studio

26. Continuous integration серверы.

27. TeamCity

28. CruiseControl

30. Это нужно для того, чтобы исследовать поведение тестируемого кода, а не его окружения (другого кода или ресурсов)

31. По степени изоляции тесты можно разделить на

32. Unit тесты

33. Интеграционные тесты

34. Функциональные тесты

36. Изоляция. Интеграционныетесты Class Внешний ресурс Unit тест Class Class Внешний ресурс

37. Изоляция. Функциональныетесты Class Внешний ресурс Unit тест Class Class Внешний ресурс

38. Изоляция. Системные тесты Class Внешний ресурс Unit тест Class Class Внешний ресурс

39. Изоляция. Основная идея Тест Испытываемая система Тестируемый объект

40. Изоляция. Основная идея Тест Испытываемая система Тестируемый объект

42. Stubs (Заглушки)

43. Fakes (Поддельные объекты)

44. Spies (Шпионы)

46. Изоляция. Stubs (Заглушки)

47. Изоляция. Fakes (Поддельные объекты)

48. Изоляция. Spies (Шпионы)

50. RhinoMock (https://github.com/ayende/rhino-mocks, Бесплатная)

53. Если не знаете с чего начать, то начинайте с мест, где есть чёткая, заранее задокументированная логика

54. Если вы думаете, что логика тестируемого кода будет сильно изменена. Взвесите все за и против прежде чем писать тесты.

55. Хорошей практикой считается создание тестов, на найденный баг.

57. Тесты должны быть быстрыми

58. Не допускаются в тестах ни условия, ни циклы

59. Тест должен быть лаконичным. Если не получается, попробуйте спрятать всю лишнюю обработку в хелперы. Краткость – сестра таланта!

60. Тест не должен проверять все возможные ситуации(и тем более позитивные и негативные тесты). Допускается вложение 2-3 ситуаций совпадающих по контексту, который должен следовать из названия теста.

62. Название тестирующего метода(теста) - должно быть не слишком длинным и должно следовать из контекста, того что вы тестируете. В названии не должно быть слов Test и Scenario. Это и так понятно.

63. Тест должен быть построен по ААА шаблону - т.е. должен содержать 3 зоны Arrange-Act-Assert. В зоне Arrange вы настраиваете контекст, в зоне Act выполняете тестируемое действие, в зоне Assert производите различные проверки.

64. Тест должен быть качественно отформатирован - в нем не должно быть лишних пустых строк и т.д.

65. В тесте должны присутствовать комментарии - обычно их пишут в зонах разделения теста, а так же в особо сложных местах. Но переусердствовать не надо...