Я только ли хотел сказать, что проектирование ведётся в диаграммах УМЛ и программисты получают картинку класса, который надо накодить. И код класса сопровождают тестами
Т.е. вы выделяете некоторого архитектора, который занимается чисто дизайном и команду программистов, которые пытаются "натянуть" дизайн на имплементацию? Если это так, то я ярый противник такого подхода... Мне вот интересно, у вас рассогласования дизайна и имплементации бывают? Какова продолжительность жизни UML диаграм?
В кратце, из репозитория извлекается текущая версия, по ней проъодят модульны тесты, склывадется их результат в файл
Реальный пример такого файла можешь привести? Мне очень любопытно.
-~{}~ 18.02.06 14:04:
Автор оригинала: whirlwind
А почему почти? Единственный вариант при котором я хоть как то могу оправдать использование мока, это самые первые препервые тесты, когда модель еще настолько абстрактна, что раскошеливаться на реальный класс рано. А еще какие могут быть варианты?
Теперь, мне кажется, я понял, что ты имел в виду под изоляцией тестов. Ты, наверное, имел в виду изолирование тестируемых сущностей друг от друга, так? Если да, то в таких ситуациях мы все же стараемся использовать моки или стабы, хотя все зависит от конкретной ситуации. Порой бывают такие случаи, когда необходимо протестировать все граничные ситуации работы одного объекта, в зависимости от другого. Пользоваться реальной имплементацией становится обычно довольно трудоемко, и здесь на помощь приходят моки. Но повторюсь, слишком злоупотреблять этим нельзя, и обычно на страже стоят не очень детальные тесты более высшего уровня.
Один из таких возможных примеров:
PHP:
class TestAcceptor{
function accept($char){}
}
Mock :: generate('TestAcceptor', 'MockAcceptor');
function testParse() {
$acceptor = new MockAcceptor();
$acceptor->expectArgumentsAt(0, "accept", array("a"));
$acceptor->expectArgumentsAt(1, "accept", array("b"));
$acceptor->expectCallCount("accept", 2);
$acceptor->setReturnValue("accept", true);
$parser = new AlphabeticCharsStringParser($acceptor);
$this->assertTrue($parser->parse("a...b.."));
}
Здесь как раз такой случай, когда непонятно, что из себя будет представлять реальный класс, поэтому в целях тестирования AlphabeticCharsStringParser был заведен псевдо-класс TestAcceptor(в принципе, можно было бы сделать псевдо-интерфейс), на который потом вешается мок.
С другой стороны, этот тест можно переписать при помощи стаба:
PHP:
class StubAcceptor {
var $result = '';
function accept($char) {
$this->result .= $char;
return true;
}
}
function testParse() {
$acceptor = new StubAcceptor();
$parser = new AlphabeticCharsStringParser($acceptor);
$this->assertTrue($parser->parse("a...b.."));
$this->assertEqual($this->acceptor->result, "ab");
}
Получается намного короче и изящнее, не так ли? И в этом случае я бы воспользовался именно стабом.
Однако бывают такие случаи, когда необходимо менять поведение инъецируемой сущности в целях тестирования различных ситуаций. В моем примере и мок, и стаб возвращают true при любом обращении к accept, но, естественно, это не всегда может быть верно, а без этого граничные ситуации протестировать невозможно. Вот здесь, как раз, и проявляется сильная сторона моков, т.к. вся необходимая инфраструктура для этого в них уже встроена. Можно, конечно, стаб также научить по-разному реагировать на различные обращения к accept, но из-за этого читабельность теста может сильно пострадать, поэтому обычно отдается предпочтение моку.
Это я все к тому, что однозначного ответа здесь нет, да и быть не должно. Поэтому я против полного отрицания моков
-~{}~ 18.02.06 14:14:
допустиам, прогрммист Василий получает задание разбработать класс, который использует класс Б, который разрабатывает Иван. КЛасса б нет. Ни в каком виде. Василий делает мок и разрабатывает класс свой. И все зашибись
Вряд ли картина настолько идеальна. Если класса Б еще нет, то придумать под него интерфейс заранее крайне сложно. У нас возникали ситуации, когда неудобства использования Б новым классом, назовем его А, заставляли Б полностью переписывать. Поэтому в этой ситуации идеальным является разработка и Б, и А в паре Василия вместе с Иваном.
