Не понимаю, как применить TDD в проекте

Question

[deilux]

Всем доброго времени суток!

Уже который год в компании пытаемся начать использовать TDD. Всё время останавливаемся по одной и той же причине: очень много логики завязано на данные.

Вот текущий пример: мы делаем систему по отслеживанию расходов сотрудников компании на определённые нужды. Ежемесячно на веб-сайт загружаются счета, парсятся, информация по расходам (кто, сколько, куда) аккуратненько раскладывается по нескольким табличкам. Каждый сотрудник может зайти на страничку, увидеть свои ежемесячные расходы, сравнить с лимитом, расстроиться при его превышении. Начальник может посмотреть информацию по всем своим подчинённым и т.д. Есть интерфейс загрузки новых счетов и просмотра деталей по старым, отчёты (с экспортом в Excel), админка, права-роли.

Звучит на словах просто, но багов и кода — не так уж и мало. С какой стороны подойти к разработке тестов? 90% функционала опирается на данные в БД, которые нужно где-то брать. Если у кого-нибудь есть опыт в подобном, подскажите!

Answer 1

[Inori]

Используйте фейковые данные, подогнанные специально под тесты. Обычно fixtures называются.

Comments

[deilux]

Данный проект изобилует DataTable, cmd.ExecuteCommand и т.д. Куда эти данные вгонять? Напрямую в БД?

[Inori]

Я в asp.net не силен, но в тех языках, которые знаю, обычно делают одно из этих:
а.) да, генерят заранее подготовленные данные в специальную _test базу
б.) создают mock объекты на репозитории, которым задают возвращение определенных данных на запросы
в.) Генераторы, например Faker на руби

Answer 2

[ishua]

Для юнит тестов обычно много данных не нужно, для того кол-ва что есть, создаются mock objects с фиктивными данными.

Comments

[deilux]

Вы можете помочь с примерами? Теорию я осознал, да. Но руки не делают (ц).
Допустим, страница с просмотром расходов пользователя: из параметров берётся user_id, дёргается хранимка, возвращающая сумму расходов по периодам, всё это отображается на страничке в таблице. И то же самое для всех подчинённых данного сотрудника, если они есть. Потенциальных мест для ошибок — немало. Но как создать для этого случая тесты?

[ishua]

Стивен Сандерсон — ASP .NET MVC Framework с примерами на C#
Во всяком случае близко к вашей тематике, там туча примеров создания тестов, они выделены отдельными абзацами.

[deilux]

Взял в руки эту книгу, нашёл главу (6, про сопутствующие инструменты: NInject, Moq). Оно? В этой главе не было ничего толкового. Создаём фейковый репозиторий, задаём ему необходимое поведение и прогоняем в тесте.

[ishua]

Эээ ну а что тогда вам собственно не понятно?:) Я так сразу и сказал, для всех внешних источников данных (или целей для данных) создаете фейковые репозитории, описываете их поведение, а затем прогоняете в тесте со своими классами и методами.

[deilux]

Я уже ответил ниже. Проект — legacy. Там нет репозиториев. Там DataTable и хранимки. И довольно обширная модель данных, которую тяжело просто так взять и описать для тестов :-( Поэтому я не знаю, с какой стороны подступиться. То ли рефакторить до внятной доменной модели, чтобы совсем не использовать БД в тестах, то ли взять тестовую БД с левыми данными, то ли взять себя в руки и написать стопку генераторов этих самых тестовых данных…

[ishua]

Собственно, все три версии возможного вы уже описали.
В принципе старые проекты, как раз по этим причинам и сложно описывать тестами, так как не всегда уровни абстракции разнесены на разные уровни :) (простите за туфталогию).

Answer 3

[LeoCcoder]

я так понимаю проект уже готов? поэтому применять TDD уже поздно, потому что основной девелопинг уже закончился.
Как бы я поступил:
Вы нашли баг, разобрались в каком компоненте системы он происходит, поняли какие входные данные нужно подсунуть компоненту, чтобы произошле баг, поняли какие данные должны получится на выходе компонента, если бы бага не было, пишете тест:
берете тестовые данные, запускаете на них ваш компонент, смотрите что получилось на выходе.

testData =…
expectedResult =…
result = youtSytemComponent.superProcessor(testData);
if (result == expectedResult) return TestSucces;
else return TestFail;

так постепенно у вас будут накапливаться тесты и вы уже не испортите, то что уже исправляли.
Базу данных настоящую использовать не обязательно, можно для тестов написать обманку, которая будет притворяться базой. Компоненты системы желательно выбирать как можно меньше, например, компонент обычно это какойто класс, созданные для определенных целей, нужно проверить правильно ли он их решает.

не все можно провестировать с помощью TDD, BDD тоже полезная вещь.

Comments

[deilux]

Да, проект уже есть, причём это жёсткое legacy, но сейчас пошла волна изменений.
Мне ваша идея нравится, сам думал в эту же сторону. Просто действительно, код явной логики не содержит, в основном это разнообразные взгляды на данные в БД (5Гб). И меня вводит в ступор логичное предложение «написать обманку». Совершенно не представляю, как!

[Николай Турнавиотов]

обманная база данных = обычная база данных но с тоестовыми значениями.
+ копия проекта, в которой вс подключения к БД идут к новой БД с тестовыми значениями.
в лучае нахождения бага и т.п. он исправляется, изменения после проверки уходят в продакшен

[LeoCcoder]

ну например чтобы проверить что данные правильно сохраняются в базу необзательно действительно их сохранять, можно проверить что до функции «сохранить_в_базу» они дошли правильно. Т.е. обманка просто проверит что они пришли правильно и сохранять их никуда не будет.

необязательно читать данные из базы, можно подсовывать заранее сформированный массив и отдавать его из функции «прочитать_из_базы», так что система не заметит никакой разницы. Вам главное проверить что прочитанные данные правильно обрабатываются, а не то что они берутся из базы.

запросы к базе тоже нужно тестировать, тут уже без самой базы никак. Нужно загрузить в базу тестовые данные для конкретного теста — выполнить запрос, проверить что получили то что надо. Для тестовых рекомендую использовать тестовую базу, а не рабочую.

[Николай Турнавиотов]

угу. особенно когда в коде одного из проектов у товарища (делавшегося достаточно давно) было полтора десятка ссылок на подключение к базе. Из которых половина — неявно выраженных…

[LeoCcoder]

поэтому TDD нужно применять с самого начала, тогда код получается модульным, если действительно следовать TDD и кучи неявных ссылок на базу просто не будет. невозможно протестировать нестируемое.

[deilux]

Спасибо за комментарии, народ!

Answer 4

[pfa]

Когда я впервые познакомился с ТДД — тоже было желание впихнуть его везде.
Прежде всего надо понимать, что ТДД — не панацея и в условиях современных проектов имеет достаточно узкую применимость, потому как хорошо работает только там, где бизнес-логика хорошо локализована и код при этом слабосвязанный.

У вас, как я понял:
1) часть бизнес-логики унесена в хранимки
2) сложная доменная модель
3) есть UI

В этом случае я бы советовал без фанатизма покрывать юнит-тестами то, что покрывается в процессе работы над текущими задачами, а основной упор сделать на интеграционные и UI-тесты.

Comments

[deilux]

Очень похоже на то, что интеграционные тесты — это как раз то, что мне и нужно. Проведу очередной рабочий день в раздумьях :-)

Answer 5

[creage]

Не уверен, на сколько мой пост будет полезен, но хочу отметить, что юнит-тестами стоит покрывать только публичные методы, public API, т.е. тот код, от которого зависят другие компоненты системы.

К примеру — есть код, который принимает что-то, и генерит что-то. Вот тут тестируем то, что он правильно принял, и вывел. Всю сопутствующую логику можно опустить.

По крайней мере мы делаем именно так.

Answer 6

[pletinsky]

Во первых Вас следует разобраться что вообще такое модульные тесты. Как правило если речь о классическим модульных тестов в рамках TDD — то это тесты на методы класса в полном отрыве от внешнего окружения. Это значит что не только данные из базы там не могут оказаться, а вообще не должно быть каких либо вызовов за пределы класса. Все мокируется. Как правило TDD (если его умеют готовить) ускоряет написание кода (хотя вы можете услышать и иное мнение — но оно неверно). И имеет массу полезных побочных эффектов, но недешево в поддержке (хотя окупается за счет большей стабильности системы).
Такие тесты требуют архитектурной готовности системы. Например ваши бизнес энтити из базы должны реализовывать какой то интерфейс для мокирования. Чаще всего юнит тесты не окупятся на уже написанном проекте.

Поймите, чего вы хотите добиться. Если Вам нужна стабильность работы каких то определенных «злых» модулей программы пишите интеграционные тесты.
Если вы хотите добиться стабильности системы по отношению к требованиям — пишите системные тесты, которые работают с приложением как с черным ящиком. Есть много наработок в этой области в рамках BDD подхода.
Если у вам не формализованы требования — первым делом этим и займитесь — иначе никакие тесты вам не помогут.

Comments

[deilux]

В принципе, соглашусь. Скорее всего я на самом деле не о TDD должен говорить, а о наличии интеграционных тестов. Принятие подобного факта снимает часть вопросов, и это уже что-то :-)

Answer 7

[meettya]

ИМХО — проблема сложности написания тестов обычно вытекает из размеров тестируемого кода.
Сложно написать тесты на кусок в 2 csloc, который разве что кофе не варит.
Если изначально с кодом не сложилось и у вас легаси, то тесты можно будет прикрутить только после рефакторинга.
Расщепляете логику на небольшие куски, которые делают мало работы и покрываете эти куски тестами.

А сейчас у вас классическая проблема — вы пытаететь съесть слона целиком :)

PS. Интеграционные тесты — штука хрупкая, можно намучится, особенно если изменения часто в коде бывают.

Comments

[deilux]

Да просто настал момент, проект получил новое развитие и очень страшно вносить изменения. Даже руками протестировать всё — непросто. Вот и ищу, с какой стороны подобраться, не отрицая возможности, что и правда пытаюсь съесть слона целиком.

[deilux]

А можете прокомментировать про хрупкость интеграционных тестов?

[pletinsky]

Об этом уже говорили. Стоимость их поддержки может быть высока. И значительно выше чем у любых других тестов.
При любом архитектурном изменении кода (включая любые добавления методов, изменения в классах — все, кроме изменения внутренностей метода) у вас будут ломаться тесты — и их придется обновлять.

[pletinsky]

Ой — сорри — думал речь о модульных тестах.
Интеграционные не должны быть хрупкими — значит фиговые тесты если так.

[meettya]

Про изменения — вот смотри (давай на ты, ок?) есть функционал «загружаются счета, парсятся, информация по расходам (кто, сколько, куда) аккуратненько раскладывается по нескольким табличкам»
Выделяем «загрузчик» в отдельный класс — покрываем класс тестами
Выделяем «парсер» в отдельный класс — покрываем класс тестами
и т.д.
рефакторинг-тест
Нашли баг — локализовали — вынесли логику в отдельный класс — написали тест не класс, тест на баг
Все просто :)

[meettya]

Хрупкость интеграционных тестов в том, что они тестят архитектуру, по факту. Если архитектура не очень хороша, а легаси сестемы обычно этим страдают — тесты будут тоже не слишком полезны.

[deilux]

Мысль уловил. Интеграционные тесты покрывают сразу большой кусок функционала. Отрефакторили внутри хоть что-то — тест может лечь. Ну, именно этого именно в данном проекте я не боюсь :)) Спасибо!

Хватит болтать, начну пробовать и есть слона (по кусочкам) :)