Как начать тестирование в антикультуре? [закрыто]

20

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

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

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

Можно ли начать личную практику тестирования программного обеспечения в культуре, которая не ценит или не предоставляет инструменты для этого? Какие методы и инструменты вы используете, чтобы позволить вам тестировать, когда в официальных инструментах и ​​организации нет места для тестов, сред и автоматизаций?

Кодзиро
источник
14
Почему вы не можете хранить тестовый код в VCS вашей компании? Я полагаю, что в проекте, в котором есть srcкаталог для производственного кода, можно было бы добавить также testкаталог - или он по какой-то причине явно запрещен?
Петер Тёрёк
@ PéterTörök Вы переоцениваете нас. У нас нет srcкаталога, у нас есть веб-корни. Чтобы проверить мой код в центральной VCS, я бы проверил его в корне сети.
Кодзиро
Если у вас нет контроля над исходным кодом в вашей культуре антитестинга, я постараюсь сделать это в первую очередь (или также), поскольку это решит множество других проблем, которые, я уверен, возникнет у вашей команды. Тогда это закладывает основу для того, что вы хотите сделать для тестирования.
Скотт Уайли
@ ScottWylie Я не совсем так сказал. У нас есть VCS, мы просто не организовали его для тестирования (или чего-то еще, кроме прямого редактирования материалов webroot). Я думаю, что чей-то племянник создал CVS в 1998 году, и никто не изменил его с тех пор.
Кодзиро

Ответы:

22

Я лично сделал это с большим успехом. Ключевые факторы успеха:

  • Получите (предварительную) поддержку управления. Преимущества автоматических тестов хорошо документированы и должны убедить любого менеджера хотя бы попробовать его. Это включает в себя поиск места в VCS и сервере сборки, потому что
  • Автоматизированные тесты дают полную ценность только в том случае, если они выполняются часто и автоматически, так что вы скоро узнаете о проблемах и не будете полагаться на людей, не забывших их запускать. Вам нужен сервер сборки, который запускает их хотя бы ежедневно. Это может быть старая рабочая станция. Дженкинс очень мало работает, чтобы начать работать.
  • Подавать пример. Пишите тесты, рассказывайте о преимуществах, которые они вам предоставляют, и когда они обнаруживают ошибки, допущенные другими разработчиками, говорите об этом с точки зрения того, как они были защищены от потенциально гораздо большего смущения.
  • Перейти на низко висящие фрукты. Некоторые части приложения будет сложно протестировать, другие - просто. Некоторые будут крепкими, другие хрупкими. Написание тестов для хрупких, но простых в тестировании деталей обеспечивает наибольшую ценность в кратчайшие сроки.
  • Посмотрите, можете ли вы написать повторно используемые тесты, например, те соглашения о тестировании или функции, которые должны иметь все модули (веб-страницы, службы REST и т. Д.), Но о которых часто забывают.
Майкл Боргвардт
источник
7

Без поддержки управления вы мертвы в воде. Руководство будет утверждать, что вы не выполняете стоящую работу, вы будете оштрафованы за ваши отзывы и, наконец, вас уволят. Есть способы привлечь руководство, чтобы увидеть, что раннее тестирование обходится им дешевле и все такое. Можно изменить культуру, но вы кладете шею на плаху.

Я бы предложил прочитать главу « Макиавелли Принц» о том, как внести изменения, прежде чем что-то делать.

Сардатрион - Восстановить Монику
источник
Ваш второй ответ предполагает, что тестирование будет стоить времени, которое иначе не было бы потрачено. Но тестирование евангелистов (как мне кажется) скажет вам, что тестирование экономит время. Не только в долгосрочной перспективе, но даже в рамках подготовки к проекту средней длины, потому что вы не будете тратить столько времени на отладку своего производственного кода, а тесты заставят вас адаптировать код для их прохождения, что (в моем понимание теории) все служит для сокращения общего времени, затрачиваемого на кодирование. Вы обнаружили, что это не так?
Кодзиро
1
@kojiro: Да, общее тестирование сократит время и затраты. Тем не менее, он не будет делать это в краткосрочной перспективе. Некоторые менеджеры считают краткосрочную перспективу более важной. В конце концов, что такое хороший программный продукт, если не тот, за который компании платят, и он может взимать с клиента плату за исправление ошибок.
Сардатрион - Восстановить Монику
2
Тестирование экономит время, но когда вам приходится переделывать половину кода, чтобы его можно было тестировать, вы сначала теряете время на выполнение всей этой работы, просто для того, чтобы через несколько месяцев пройти тестирование, а затем оно ускоряется. Менеджеры не думают в «месяцы спустя», они думают «в этом месяце», поэтому все, что они когда-либо видят, - это «пустая трата времени», потому что этот разработчик не создает новый код, в который они играют с помощью тестов, которые мы можем ». продать или, что более вероятно, сделать рефакторинг кода, который «уже работает»
Уэйн Молина
Обычно даже в краткосрочной перспективе это сэкономит время. Когда вы работаете над чем-то, гораздо быстрее иметь возможность выполнить фрагмент кода с помощью теста, а затем запустить все приложение и заставить его выполнить этот конкретный фрагмент кода.
Стефан Биллиет
3

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

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

Уэйн Молина
источник
1

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

Если существует культура ручного тестирования с использованием определенных сценариев, то стоит выполнить эти сценарии в сочетании с риском неполных или неточных результатов. Это может быть история (задокументированная или в форме «военной истории»). Предложите пилотный проект для автоматизации некоторых из этих ручных тестов с целью обеспечения долгосрочной экономии средств.

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

Майк Вудхаус
источник
0

Одна из идей заключается в том, что вы хотите написать тест, который доказывает, что код, написанный кем-то другим, неисправен. Должен продать концепцию.

Андерс Линден
источник