эээ, сложно сказать. как минимум "что эта функция должна делать?", "какую гарантию (факт) я хочу получить?", "какие side-эффекты у этой функции?", "не делает ли она слишком много?". а в данном посте я имел в виду недостатки конкретно библиотеки mock (и, как следствие, возможность ёе улучшить).
я раньше думал, что TDD для ебанутых, потому что думал, что там вся соль про то, что сначала тесты, а потом код. а потом понял, что идея немного в другом, и, хотя они всё еще ебанулись, здравый смысл есть.
Вся суть TDD (который, как я повторюсь, является утопией для меня и конечно же в реальной жизни я так делаю не всегда):
ты обязан придерживаться 3 правил: 1. сначала пишешь падающий тест ровно до тех пор, пока он не стал failing-тестом (то есть объявил все нужные функции, написал минимум теста, он уже падает не в Error, а в Fail). 2. как только он падает — тут же бросаешь его, и идёшь писать реализацию, пока она не удовлетворит тесту. 3. как только она удовлетворяет тесту — ты тут же останавливаешься и не пишешь ни строчки кода более. дальше, я так понял, варианты или рефакторинга или заново в цикл.
короче, хоть это и тупость, благодаря этому я частенько останавливаю себя при написании как кода так и тестов и меня лишний раз не уносит в говнотворчество.
ДРОЧУ НА КОВРОВАНИЕ
???
какими суждениями ты руководствуешься при написании тестов?
эээ, сложно сказать. как минимум "что эта функция должна делать?", "какую гарантию (факт) я хочу получить?", "какие side-эффекты у этой функции?", "не делает ли она слишком много?". а в данном посте я имел в виду недостатки конкретно библиотеки mock (и, как следствие, возможность ёе улучшить).
а как ты выбираешь функции?
никак не выбираю, все тестирую
ну, оооооооооооооооооок
я раньше думал, что TDD для ебанутых, потому что думал, что там вся соль про то, что сначала тесты, а потом код. а потом понял, что идея немного в другом, и, хотя они всё еще ебанулись, здравый смысл есть.
Вся суть TDD (который, как я повторюсь, является утопией для меня и конечно же в реальной жизни я так делаю не всегда):
ты обязан придерживаться 3 правил:
1. сначала пишешь падающий тест ровно до тех пор, пока он не стал failing-тестом (то есть объявил все нужные функции, написал минимум теста, он уже падает не в Error, а в Fail).
2. как только он падает — тут же бросаешь его, и идёшь писать реализацию, пока она не удовлетворит тесту.
3. как только она удовлетворяет тесту — ты тут же останавливаешься и не пишешь ни строчки кода более. дальше, я так понял, варианты или рефакторинга или заново в цикл.
короче, хоть это и тупость, благодаря этому я частенько останавливаю себя при написании как кода так и тестов и меня лишний раз не уносит в говнотворчество.
ну, ты собственно и описал то, как надо.
Подожду треда покрупнее чтобы набросать срач :3
да уж, давай покрупнее. а то пост я, чувствую, никогда не допишу, или его никогда не прочтут массы, потому у меня руки опустились.
Аааа. Под "КОВРОВАНИЕ" ты имел в виду coverage? :) А то я до сих пор не понял.
йеп