Начало работы в модульном тестировании как группы в эти экономические времена - PullRequest
3 голосов
/ 03 февраля 2009

У нас есть группа из нескольких разработчиков и несколько бизнес-аналитиков. Мы, как разработчики, хотели бы начать добавлять модульное тестирование как часть нашей практики кодирования, чтобы мы могли предоставлять поддерживаемый и расширяемый код, тем более что мы будем теми, кто будет поддерживать и улучшать приложение в будущем. Но в этом экономическом спаде мы боремся с тем, чтобы начать работу, потому что нам нужно просто предоставлять решения как можно быстрее, причем качество не является главным приоритетом. Что мы можем сделать или сказать, чтобы показать, что мы сможем доставить быстрее и с более высоким качеством, а также подготовиться к будущим улучшениям.

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

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

EDIT Всем отличный вклад, спасибо. Я лично знаю, как написать модульный тест, но у меня нет опыта, чтобы сказать, хорош ли этот модульный тест. Я только что заказал Test Driven Development: By Example и возьму на себя инициативу, чтобы добиться успеха при включении юнит-тестирования в нашу группу.

Ответы [ 6 ]

5 голосов
/ 03 февраля 2009

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

2 голосов
/ 04 февраля 2009

Вам даже не нужно обсуждать это с руководством (хотя описанная вами ситуация далека от идеальной). Это как Design by Contract - я представил его в предыдущем коде, над которым работал, просто как часть процесса разработки. Как только он войдет и сработает, поверьте мне, никто не посмеет его удалить.

Модульное тестирование также можно рассматривать как часть разработки. Следовательно, если у вас есть «20 дней» для разработки функций A, B и C, вы можете включить модульные тесты в свои оценки для самой разработки.

Создание модульных тестов на удивление легко. По сравнению с проблемами многопоточности или любым другим сложным дизайном модульное тестирование очень легко понять любому компетентному разработчику.

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

Действительно - просто сделай это!

2 голосов
/ 03 февраля 2009

Запустите модульное тестирование функций или классов при их создании. Начните с простых классов / функций, которые не имеют внешних зависимостей (БД, файловая система).

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

Прочтите о TDD: " Разработка через тестирование: на примере ". Написание тестов сначала приводит к коду, который можно легко протестировать. Если вы сначала напишите производственный код, вам может быть трудно его протестировать.

2 голосов
/ 03 февраля 2009

Просто сделай это ...

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

Подумайте об этом со стороны бизнеса, зачем вам писать код, чтобы доказать, что код, который вы уже написали, верен? Почему это неправильно?

Было бы неплохо получить 100% охват, но не торопитесь и не пишите тесты для существующего кода, который в настоящее время не ошибается; пишите тесты так, как они ломаются, так что вы, по крайней мере, никогда не отменяете что-то непреднамеренно.

2 голосов
/ 03 февраля 2009

Я хотел бы рекомендовать книгу Прагматическое тестирование программного обеспечения

Книга Прагматическое модульное тестирование также является хорошей книгой, хотя в ней больше внимания уделяется C # и NUnit, есть темы, которые применимы независимо от языка

1 голос
/ 03 февраля 2009

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...