Питер, опытный программист требуется, $1800

[Pigmeich]

если тесты в 3 раза больше остального кода, нафиг такие тесты

Это от важности кода зависит.

И от сложности тестов - как показывает практика, минимум половина тестов делается методом копи-паста.

whirlwind
Так ты не ответил - пицца есть?

Это при том, что даже приверженцы TDD утверждают, что методика позволяет выявить до 30% ошибок. Ну и что еще можно сказать о такой методике работы?

Это не приверженцы TDD, это независимые эксперты и консультанты утверждают. По крайней мере, именно этот процент я видел у МакКоннелла, который достаточно иронично относиться к XP.

Впрочем, TDD - не методика QA отдела, потому мерить ее одними процентами найденных ошибок - неправильно. Вон, недавно, один парень даже утверждал, что она поднимает стиль программирования. А если сильно уверовать, то даже еще кое-что поднимает. Это все, конечно, спорно, но польза от TDD действительно выходит за рамки обнаружения ошибок.

Например, TDD позволяет выделять центры ответсвенности за код: если у разработчика работают все тесты он может смело посылать всех кричащих: "У тебя в коде ошибка!". Если ошибка, то пусть делают тест, а если тест проходит (т.е. завалился) - стучат по голове разработчика. Но пока не прошел - разработчик неприкасаем, что экономит время и нервы.

-~{}~ 27.12.07 13:52:

whirlwind
У вас alt на банере SmartSite CMS с текстом банера не совпадает.

 

[whirlwind]

если тесты в 3 раза больше остального кода, нафиг такие тесты

Между объемом тестов и качеством тестируемого кода можно пронаблюдать зависимость. Если тест больше тестируемого кода, значит вы подумали над многими ситуациями, а это в свою очередь свидетельствует о том, что класс прекрасно справляется со своей работой. Если объем тестируемого кода сопоставим с объемом теста, значит класс умеет слишком мало или вы не проработали все частные случаи достаточно детально. Первое - залог будущей помойки, второе чревато, чем - я думаю понятно каждому.

Действительно, нафиг такие тесты. Больше 60-80% процентов от тестируемого кода - многовато.

Ваши % окупаются тем, что вы более эффективно можете повторно использовать свой код. Больше 60-80% на юнит, а не на весь проект. Разницу понимаете?

 

[Alexandre]

Ваши % окупаются тем, что вы более эффективно можете повторно использовать свой код.

маловероятно...
повторно используется классы CMF (если ты ее не разрабатываешь)
пользовательские классы, как правило - уникальны и их повторное использование маловероятно.

 

[whirlwind]

как правило - уникальны и их повторное использование маловероятно.

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

require_once 'BasicEditController.php';
require_once 'mvc/listcreator/PersistentBasedList.php';

class ExchangeRateEdit extends BasicEditController {

    protected function _getObjectClass(){
        return 'ExchangeRate';
    }

    protected function _registerRequisites(){
        parent::_registerRequisites();
        $listCreator = new PersistentBasedList();
        $param = MetaData::createObject('Exchanger');
        $param->orderBy('display_name');
        $this->attachListRequisiteCreator('exchanger',$listCreator,$param);
        $param = MetaData::createObject('ExchangeWay');
        $param->orderBy('subject');
        $param->addOrderBy('target');
        $this->attachListRequisiteCreator('exchange_way',$listCreator,$param);
        $this->getRequisite('update_time')->setTransferToModel(false);
    }

}

require_once 'BasicEditController.php';

class ExchangerEdit extends BasicEditController {

    protected function _registerRequisites(){
        parent::_registerRequisites();
        $this->setRequisite('status',new RequisiteList('status',true,true));
    }
    
    public function prepareListRequisite(RequisiteList $requisite){
        switch ( $requisite->getId() ){
            case 'status':
                $order = Array(
                    Exchanger::STATUS_DISABLED,
                    Exchanger::STATUS_OK,
                    Exchanger::STATUS_WARNING,
                    Exchanger::STATUS_BANNED);
                $dict = LocalProject::getInstance()->getDictionary();
                foreach ( $order as $status ){
                    $requisite->addListItem($status,
                        $dict->getExchangerStatus($status));
                }
                return true;
        }
        return parent::prepareListRequisite($requisite);
    }

    protected function _getObjectClass(){
        return 'Exchanger';
    }

}

require_once 'BasicEditController.php';
require_once 'mvc/listcreator/PersistentBasedList.php';

class ExchangeUnitDisplayOrderEdit extends BasicEditController {

    protected function _getObjectClass(){
        return 'ExchangeUnitDisplayOrder';
    }

    protected function _registerRequisites(){
        parent::_registerRequisites();
        $listCreator = new PersistentBasedList();
        $param = MetaData::createObject('ExchangeUnit');
        $param->orderBy('display_name');
        $this->attachListRequisiteCreator('unit',$listCreator,$param);
    }

}

Вот, здесь всего лишь 3 класса. И я тебе кучу подобных классов приведу, которые не нужнаются в тестировании, потому что вся их логика на виду. Пусть объем тестов для базы составляет 300% от кода базы, а объем тестов каждого контроллера, если бы мы писали его "с нуля" составил всего 100% (плохенькие такие тесты, написанные кое-как, так как нам лень) от кода контроллера. Уже на 3х классах мы получаем равные объемы тестов. Дальше идет только выигрыш в пользу TDD. А сколько контроллеров форм редактирования в типовом проекте я думаю все примерно могут оценить.

 

[zerkms]

[off]

маловероятно...

Спорить можно до бесконечности

проводя аналогию: не тддшник тдшнику не товарищ (никого не пытаясь принизить этой фразой)
заражённые техникой - будут с пеной у рта доказывать как всё хорошо, не пробовавшие, или имевшие плохую тдд-практику (причин - куча) - будут на каждом углу кричать что это удобно и лишняя трата времени и сил
[/off]

 

[Alexandre]

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

zerkms, ни кто не доказывает, что TDD - это плохо, я сам за TDD практику ...