Comments 11
Глаза ищут статический класс Assert и не находят, что вызывает легкое недоумение
С человеческим восприятием спорить глупо. В именовании фикстур проверок я ставлю на первое место слово Assert. Например: AssertReadonly.
С человеческим восприятием спорить глупо. В именовании фикстур проверок я ставлю на первое место слово Assert. Например: AssertReadonly.
AAA — интересная концепция. Думаю, многие интуитивно стараются ей следовать, но если возвести ее в ранг правила при написании тестов, читабельность существенно увеличится.
Что касается нескольких тестовых классов (и файлов) на один класс модели. Мне кажется это неправильным нескольким причинам:
1. Неудобно искать тест для конкретного класса.
2. Неудобно использоваться тест как документацию (приходится бегать между классами).
3. Самое главное: если класс модели большой и требует большого теста, самое время подумать о рефакторинге «выделение класса».
В целом, полезная публикация, спасибо.
Что касается нескольких тестовых классов (и файлов) на один класс модели. Мне кажется это неправильным нескольким причинам:
1. Неудобно искать тест для конкретного класса.
2. Неудобно использоваться тест как документацию (приходится бегать между классами).
3. Самое главное: если класс модели большой и требует большого теста, самое время подумать о рефакторинге «выделение класса».
В целом, полезная публикация, спасибо.
1. Неудобно искать тест для конкретного класса.Часто приходится это делать? Если тесты похожие в чем-то, то значит тестовый класс лежит недалеко от текущего. А если править падающие, так до них навигация моментальная.
2. Неудобно использоваться тест как документацию (приходится бегать между классами).в моей практике написание всех тестов в один класс приводило к тому, что логические границы тестов получаются размазаны. Трудно найти кусок класса, где проверяется какой-то метод и дописать туда тест. Чаще все валится в конец класса и потом трудно смотреть. Но если есть очень хорошая дисциплина, то можно и в один класс писать все тесты.
Стандартный юзкейз: есть класс, хочешь посмотреть как он работает — ищешь тест, читаешь. В случае с несколькими файлами это сделать гораздо сложнее, как мне кажется.
И, повторюсь, в случае небольших классов (а они должны быть небольшими, иначе — выделение класса) необходимость дробить тесты отпадает сама собой. Более 200 строк — это большой класс, больше 500 — огромный. Плюс не стоит забывать о том, что тестирование — это далеко не основная задача TDD и слишком тщательное тестирование — плохой запах.
Все вышесказанное относится к модульному тестированию.
И, повторюсь, в случае небольших классов (а они должны быть небольшими, иначе — выделение класса) необходимость дробить тесты отпадает сама собой. Более 200 строк — это большой класс, больше 500 — огромный. Плюс не стоит забывать о том, что тестирование — это далеко не основная задача TDD и слишком тщательное тестирование — плохой запах.
Все вышесказанное относится к модульному тестированию.
У нас на одну сущность/аспект/фитчер (это может быть несколько класов) заводится целая папка, а и одна тест фикстура на каждый сценрий. Поэтому читаем мы обыно по названиям файлов ;).
У меня чаще возникает потребность выяснить как работает конкретная фича/сценарий, поэтому поддерживаю автора. К тому же, завязка тестов на структуру классов сильно затрудняет рефакторинг (не говоря уже про переименование классов).
Этих Should DSLей развелось што капец. Если в Нюгет поискать, то наверное свободно можно больше десятока найти. Отличия обычно тока в каком месте стоит точка, и знании английского у разработчиков.
Я бы рекомендовал юзать что-то уже готовое, чем велосипед (собсно я так и делаю, хотя у меня самого есть такой фремвфорк, правда для F# :).
Я бы рекомендовал юзать что-то уже готовое, чем велосипед (собсно я так и делаю, хотя у меня самого есть такой фремвфорк, правда для F# :).
Можете посоветовать что-то готовое? Да, NuGet выдает 20 вариантов всяких готовых Should. Что-то я не подумал поискать готовые решения для базовых случаев. Спасибо за мысль.
DSL на то и specific, что универсального не может быть по определению. Только самые финальные методы и то не всегда. Но все равно, интересно было бы посмотреть на предлагаемые «готовые» решения.
DSL на то и specific, что универсального не может быть по определению. Только самые финальные методы и то не всегда. Но все равно, интересно было бы посмотреть на предлагаемые «готовые» решения.
Большая часть Should фремвокров расширяема (один и тот же принцип, екстеншен методы, раширения тож переносятся без проблем). Поэтому обычно проще дописать того чего не хватает.
Пользовался nuget.org/List/Packages/SharpTestsEx (когда он еще был NUnitEx)
Щас по большей части пользуюсь nuget.org/List/Packages/ShouldFluent или nuget.org/List/Packages/FluentAssertions
Разница нулевая, пользоваться начинаю обычно тем что раньше попадется в Nuget.
Пользовался nuget.org/List/Packages/SharpTestsEx (когда он еще был NUnitEx)
Щас по большей части пользуюсь nuget.org/List/Packages/ShouldFluent или nuget.org/List/Packages/FluentAssertions
Разница нулевая, пользоваться начинаю обычно тем что раньше попадется в Nuget.
Наверно, всё-таки fluent inerface, а не fluid.
Я пользуюсь чем то похожим на Java: библиотека fest-assert. code.google.com/p/fest/
Sign up to leave a comment.
Assert DSL на примере .Net