Unit tests

1,393 views

Published on

Theory and practice of unit tests

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,393
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
20
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • Добрый день меня зовут Цуканов Павел. Я являюсь исполнительным директором Codemasters. Наша юзер группа сегодня стартует новый сезон в другом месте. И я надеюсь, что в этом году активность этой группы увеличится. Во всяком случае, мы приложим для этого все усилия
  • Итак темы, которые мы рассмотрим, в этом докладе......Изоляция в Юнит тестах. Рассмотри важный момент, на который требуется обратить своё внимание. Потому как без изоляции ваши тесты могут превратиться в груду не нужного хлама.От теории к практике – рассмотрим небольшое приложение и тесты для негоВредный советы – попытался изложить свои мысли по поводу того как надо писать тестыТребования к тестам и правила оформления. Эти разделы очень важены потому, что без следования требованиям и правилам вы рискуете получить плохие тесты. И ваши коллеги скажут вам своё ФИ.
  • Unit tests

    1. 1. Unit тесты теория и практика<br />Цуканов Павел<br />ptsukanov@codereign.net<br />
    2. 2. Содержание<br /><ul><li>Что такое Unit тесты и с чем их едят
    3. 3. Unit Test инструменты
    4. 4. Изоляция в Unit тестах
    5. 5. От теории к практике
    6. 6. Вредные советы
    7. 7. Требования к тестам
    8. 8. Правила оформления</li></li></ul><li>Что такое Unit тесты и с чем их едят<br /><ul><li>Unit – это атом тестирования.
    9. 9. Тест пишут программисты
    10. 10. Тесты показывают насколько корректно работает та или иная часть программы</li></li></ul><li>Преимущества Unit тестов<br /><ul><li>Поощрение изменений
    11. 11. Упрощение интеграции
    12. 12. Документирование кода
    13. 13. Отделение интерфейса от реализации</li></li></ul><li>Ограничения Unit тестов<br /><ul><li>Unit тесты могут показать только наличие ошибки, а не их отсутствие.
    14. 14. Тесты требуют много кодирования (тесты могут занимать от 50 до 80%).
    15. 15. Не всё можно проверить
    16. 16. Сам тест может содержать ошибки
    17. 17. Важна строгая дисциплина при разработке. Тесты должны быть запущены вовремя и выявленные ошибки были немедленно устранены </li></li></ul><li>Unit Test инструменты<br /><ul><li>Unit тесты разрабатываются для различных языков программирования (см. http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks)
    18. 18. Для создания тестов нужен framework. Наиболее часто используемые для .Net
    19. 19. Nunit (www.nunit.com)
    20. 20. xUnit ( xunit.codeplex.com)
    21. 21. Visual Studio Unit Test Framework
    22. 22. Интеграция со средой разработки.
    23. 23. ReSharper
    24. 24. TestDriven.net
    25. 25. Visual Studio
    26. 26. Continuous integration серверы.
    27. 27. TeamCity
    28. 28. CruiseControl
    29. 29. Team Foundation Server</li></li></ul><li>Изоляция в Unit тестах<br /><ul><li>Тест не должен иметь других зависимостей, чем сам тестируемый код
    30. 30. Это нужно для того, чтобы исследовать поведение тестируемого кода, а не его окружения (другого кода или ресурсов)
    31. 31. По степени изоляции тесты можно разделить на
    32. 32. Unit тесты
    33. 33. Интеграционные тесты
    34. 34. Функциональные тесты
    35. 35. Системные тесты</li></li></ul><li>Изоляция. Unit тесты<br />Class<br />Внешний ресурс<br />Unit тест<br />Class<br />Class<br />Внешний ресурс<br />
    36. 36. Изоляция. Интеграционныетесты<br />Class<br />Внешний ресурс<br />Unit тест<br />Class<br />Class<br />Внешний ресурс<br />
    37. 37. Изоляция. Функциональныетесты<br />Class<br />Внешний ресурс<br />Unit тест<br />Class<br />Class<br />Внешний ресурс<br />
    38. 38. Изоляция. Системные тесты<br />Class<br />Внешний ресурс<br />Unit тест<br />Class<br />Class<br />Внешний ресурс<br />
    39. 39. Изоляция. Основная идея<br />Тест<br />Испытываемая система<br />Тестируемый объект<br />
    40. 40. Изоляция. Основная идея<br />Тест<br />Испытываемая система<br />Тестируемый объект<br />
    41. 41. Изоляция. Test Doubles<br /><ul><li>Dummies (Пустые объекты)
    42. 42. Stubs (Заглушки)
    43. 43. Fakes (Поддельные объекты)
    44. 44. Spies (Шпионы)
    45. 45. Mocks (Объекты имитаторы)</li></li></ul><li>Изоляция. Dummies (Пустые объекты)<br />
    46. 46. Изоляция. Stubs (Заглушки)<br />
    47. 47. Изоляция. Fakes (Поддельные объекты)<br />
    48. 48. Изоляция. Spies (Шпионы)<br />
    49. 49. Изоляция. Mock (Объекты имитаторы)<br /><ul><li>TypeMock (http://www.typemock.com, Платная)
    50. 50. RhinoMock (https://github.com/ayende/rhino-mocks, Бесплатная)
    51. 51. MOQ (http://code.google.com/p/moq/, Бесплатная )</li></li></ul><li>От теории к практике<br /><ul><li>Посмотрим на реальном примере как можно применить теорию на практике
    52. 52. Рассмотрим пример небольшой библиотеки и тесты для неё.</li></li></ul><li>Вредные советы<br /><ul><li>Тесты создавать никогда не рано и никогда не поздно
    53. 53. Если не знаете с чего начать, то начинайте с мест, где есть чёткая, заранее задокументированная логика
    54. 54. Если вы думаете, что логика тестируемого кода будет сильно изменена. Взвесите все за и против прежде чем писать тесты.
    55. 55. Хорошей практикой считается создание тестов, на найденный баг.
    56. 56. Будьте добры к коллегам, потому как тесты в первую очередь адресованы им</li></li></ul><li>Требования к тестам <br /><ul><li>Тесты должны быть переносимыми, и не зависть от конфигурации компьютера, на котором они написаны
    57. 57. Тесты должны быть быстрыми
    58. 58. Не допускаются в тестах ни условия, ни циклы
    59. 59. Тест должен быть лаконичным. Если не получается, попробуйте спрятать всю лишнюю обработку в хелперы. Краткость – сестра таланта!
    60. 60. Тест не должен проверять все возможные ситуации(и тем более позитивные и негативные тесты). Допускается вложение 2-3 ситуаций совпадающих по контексту, который должен следовать из названия теста.
    61. 61. Следуйте установленным правилам оформления тестов</li></li></ul><li>Правила оформления тестов <br /><ul><li>Название тестового класса - тестовый класс должен называться относительно класса, который должен быть протестирован с добавлением окончания Test. Допускается, иногда, для группировки сложных однотипных тестов вместо Test использовать Scenarios
    62. 62. Название тестирующего метода(теста) - должно быть не слишком длинным и должно следовать из контекста, того что вы тестируете. В названии не должно быть слов Test и Scenario. Это и так понятно.
    63. 63. Тест должен быть построен по ААА шаблону - т.е. должен содержать 3 зоны Arrange-Act-Assert. В зоне Arrange вы настраиваете контекст, в зоне Act выполняете тестируемое действие, в зоне Assert производите различные проверки.
    64. 64. Тест должен быть качественно отформатирован - в нем не должно быть лишних пустых строк и т.д.
    65. 65. В тесте должны присутствовать комментарии - обычно их пишут в зонах разделения теста, а так же в особо сложных местах. Но переусердствовать не надо...
    66. 66. Фиксируйте написанные тесты в комментариях к тестируемому члену класса - это позволит быстро выходить на тесты, которые проверяют данный член класса.</li></li></ul><li>Спасибо за внимание!<br />

    ×