Как использовать TDD в не очень “Вспыльчивой” среде
Я работаю в компании, где ООП... хорошо, не fobidden, но по крайней мере осужденный как "слишком сложное". Мои коллеги пишут много из 100 + функции строк, и они обычно - все в "funcs.inc.php" или "something.inc.php", если они используют какие-либо функции вообще, часто они не делают, так как вставка копии быстрее.
Я хотел бы начать использовать TDD, по крайней мере, для кода, который я пишу, но поскольку я должен взаимодействовать через интерфейс с их кодом, который я не вижу, как начать.
Это не унаследованный код, поскольку они активно разрабатывают его, и я не хочу изменять их код, поскольку я не хочу вызывать конфликты.
Какой подход Вы предложили бы, за исключением изменения компании?
5 ответов
Я был в таком положении, как в состоянии вне реального TDD. Обычно я пишу тесты для чужих интерфейсов, когда это возможно. Затем я знаю, прежде чем запустить свой код, сделали ли они одну из многих обычных вещей, которые делают люди:
- Сломали API, переименовав или полностью отказавшись от чего-то
- Сломали API с тонкими изменениями типов, которые не выполнялись. быть замеченным
- Выдвинул токсичную ревизию, не тестируя ее
- Возникли утечки памяти (мой набор тестов знает Valgrind)
- Заблокировать, где они никогда не блокировались раньше
Любой из этих сбоев обычно приводил к тому, что я говорил: «Привет Можете ли вы проверить (модуль), я думаю, что он сломался в последней ревизии »
Это было некрасиво только один раз. Кто-то был очень расстроен тем, что я писал тесты для их кода, и настаивал на том, что я не выполняю их работу. Я не мог заставить этого человека понять, что я просто хотел облегчить свою работу.
Никогда не стоит сразу сказать: «Послушайте, я трачу больше времени на отладку вашего кода, чем на работу над собой», за исключением случаев, когда это абсолютно необходимо (т. Е. Ваш босс спрашивает о вашей производительности). В большинстве случаев, если вы просто отправите людям тесты, они будут счастливы получить их. Если эта идея уже встречает сопротивление, просто постарайтесь никого не обидеть и не показаться снисходительным.
Поддельные функции / заглушки - это нормально, но остается только то, что программа в целом может сломаться, если не запустить настоящие тесты. По крайней мере, когда это произойдет, вы можете быстро исключить свои вещи и (вероятно) указать прямо на проблему.
Используйте TDD для всех своих модулей и пишите тесты, когда вы используете их модули для чего-то. В конце концов, все остальные заметят, что вы создаете высококачественный код намного быстрее, чем кто-либо другой, и им будет любопытно, почему. Это будет прекрасная возможность обучить их.
Если они никогда не спросят, что ж, по крайней мере, вы облегчили себе жизнь.
Я бы посоветовал начать с того, что вам нужно написать, и попытаться сначала выполнить несколько тестов, а затем написать код для этого. Это может быть исправление ошибки, реализация улучшения или новой функции, но идея состоит в том, чтобы попытаться найти способ провести тесты до внесения изменений.
В качестве альтернативы, вы можете взять код своих коллег, обернуть вокруг него тесты и попытаться его реорганизовать, но я не уверен, насколько хорошо это пройдет.
Вы, вероятно, захотите протестировать свой код отдельно от их кода. Это изменит то, как вы разрабатываете свой код, но, вероятно, именно поэтому вы все равно хотите использовать TDD.
Создайте фиктивные функции для библиотек, от которых вы хотите изолировать себя.
Можете ли вы сначала написать модульные тесты для своего собственного кода? Не заморачивайтесь на других людях; убедитесь, что ваш код полностью Tdded и юнит-тестирован.
Чтобы имитировать взаимодействие с другими библиотеками, вы можете попробовать такие проверенные и верные техники, как mocks и stubs.