acerv Jan 18 2009 at 15:18

Оптимизация процесса создания unit-тестов

6 min

4.8K

Programming*.NET*C*

+14

Comments 17

Timmmm Jan 18 2009 at 15:28

Давно хотел заняться юнит тестированием, но как-то руки не доходили. Ждем продолжение…

acerv Jan 18 2009 at 15:32

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

Если и будет какое-то продолжение, то исключительно по возможностям мок-фреймворка Rhino Mocks.

Xeon303 Jan 19 2009 at 01:33

Эх… только единицы разработчиков в полной мере пользуются TDD :( Возможно, если бы все руководствовались бы такой методикой, то дырявого ПО было бы гораздо меньше.

acerv Jan 19 2009 at 01:35

Я стараюсь сделать мир лучше:) Вот своих коллег-разработчиков постоянно идеологически обрабатываю. Вот еще и статью написал — может, поможет кому:)

malkolm Jan 19 2009 at 04:32

Подготовить какую никакую матбазу и основываясь на ней делать дальнейшие выводы — это сильно и неожиданно.

scorzh Jan 19 2009 at 05:26

А по-моему это должно быть стандартным подходом. Осознал, сформулировал, доказал (обосновал) — затем уже сделал. А не «показалось — сделал — переделал — переделал — переделал».

gadub Jan 19 2009 at 12:30

тут скорей не матбаза, а запись обывательских рассуждений матсимволами

acerv Jan 19 2009 at 15:40

Хм. Это хорошо, плохо? Что плохого в том, что эти «матсимволы» помогли мне найти результат и определить методику?

gadub Jan 19 2009 at 16:01

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

acerv Jan 19 2009 at 16:02

Специально для благодарных слушателей приводится интересный пример:) Спасибо за отклик, btw

malkolm Jan 19 2009 at 22:32

Это хорошо, но специфично. Все же люди как то больше ложками и поварешками мыслят.

chiaroscuro Jan 19 2009 at 07:15

Статью Вашу не понял, но посмотрите QuickCheck.

Там небольшой DSL для
— генерации входных данных
— указания свойств функции
— автоматического проведения тестов

acerv Jan 19 2009 at 15:59

Спасибо, погляжу:)

gadub Jan 19 2009 at 10:51

$a(z_0)$ или $a(h, x_0, z_0)$?
т.е. ассерт зависит только от конечного результата?

acerv Jan 19 2009 at 15:58

Я привел первый случай, потому как важно определить конечный результат. Почему важно? Чтобы не допустить ошибку в логике f(x). $a(h, x_0, z_0)$ — мне, если честно, не совсем понятен смысл этой конструкции. Дополнительные ассерты всего и вся? В том числе и функциональности теста? Чтож, можно и так — добавляется пятый шаг, на котором программист «усиляет» проверки (если они уместны).

gadub Jan 19 2009 at 16:03

правильней так было бы: $a_{h}(x_0, z_0)$

потому что функция проверки корректности зависит от проверяемого отображения, а результат её выполнения — ещё и от входных и выходных данных

acerv Jan 19 2009 at 16:15

Хм. Результат выполнения выдает z0. Т.е. опять же, h(x0) = z0 — это следует из определения функции, а сама конструкция определяет юнит-тест. Поэтому в конечном итоге все равно требуется только a(z0). Если честно, я не вижу смысла писать ассерты на код в h(x) — опять, из выведенного в статье h(x) = f(m(x)), а моки — не изменяют данные. Посмотрите в код, шаг 3, определяется мок, выдающий данные через заглушку ITopologyService. Он не изменяет данные, он их выдает в тестируемый класс как результат вызова метода ITopologyService.