Unit tests quickstart
24/6/08 13:57Originally published at Fiberglass flowers. You can comment here or there.
A friend asked me for it, so probably someone might need a jumpstart in unit tests.
Here’s a short list of short (though very deep, if not best) intros.
- Except for JUnit cookbook (~2 pages) (which has a lot of “ports”, like CppUnit cookbook), I’d name:
- “Endo-Testing: Unit Testing with Mock Objects” at mockobjects.com (Tim Mackinnon, Steve Freeman, Philip Craig) (7 pages);
- “Mocks aren’t stubs” by Martin Fowler (about 7 pages);
For deeper dive, take a “xUnit patterns” book (this one is longer).
For Kent Beck’s book on TDD, shame on me - I never read it. Though after “XP explained” I don’t strive for reading his books.
// If you’re interested in XP and “XP explained” criticism, take a look at “Extreme Programming Considered Harmful for Reliable Software Development” by Gerald Keefer.
Tags:
Развивая тему
24/6/08 13:15 (UTC)"Если не видно разницы, то зачем платить больше?" Это я про мок объекты. Нафига они?
Разница в том, что они:
1. Не требуют создавать себе экземпляров прилегающих классов, т.е. инициализируются на порядок проще;
Потому что в плохих случаях нередка такая ситуация - чтобы создать экземпляр класса, нужно инициализировать пол-фреймворка.
2. Сами делают проверки, нужные ли вызовы делаются и в нужной ли последовательности;
3. Их можно написать совсем тупо.
4. Они поощряют low coupling и code for interface.
Ну, раз уж ты объяснил первый пункт, поясни и про то, как так сочетаются второй с третьим?
Очень просто. Все методы бросают NotImplementedException, а один тестируемый возвращает тестовый объект и подсчитывает количество вызовов.
А ты потом проверяешь, чтобы не было лишних вызовов.
И последовательность их тоже подсчитываешь и проверяешь.
Возникает мысль, что тут тоже нелишними были бы монады. ;)))
Впрочем, вообще выработался стереотип: жёсткая последовательность => monads.
Наверное, не пробовал.
На императивных языках это выражается через state.
(no subject)
24/6/08 15:20 (UTC)"Бывают просто сны", то есть такой код, что все кишки класса завязаны на кишки другого класса. Надеюсь, всё не так плохо.
Пусть есть класс A, завязанный на классы B, C, D...
У нас есть такие рефакторинги:
* спрятать класс B за как можно более простым интерфейсом, и для теста написать и юзать MockB;
* все методы A, завязанные на класс C, вынести в отдельный класс-стратегию, и в тесте подменять его mock-ом;
* все методы, завязанные на класс D, переопределить в классе ATested extends A, скажем, как пустые операции, и тестировать ATested;
В не самых запущенных случаях этих приёмов мне хватает, чтобы развязаться с coupling-ом.
(no subject)
24/6/08 19:00 (UTC)