Сколько поблочного тестирования является хорошей вещью? [закрытый]

Хотя можно перепроверить (точка убывающей отдачи) это сделать сложно. Тестирование (особенно тестирование на ранней стадии) экономит время. Чем дольше дефект остается в продукте, тем дороже его устранение.

Часто тестируйте ранний тест и тестируйте настолько полно, насколько это возможно!

I'd suggest picking up the book The Art of Unit Testing. Chapter 8 covers integrating unit testing into your organization. There's a great table (p. 232) that shows the results of a two-team trial (one using tests, one without); the test team shaved two days off their overall release time (including integration, testing, and bug fixing) and had 1/6 the bugs found in production. Chapter 9 discusses test feasibility analysis for getting the most bang-for-the-buck with legacy code.

How much unit testing is a good thing :

Unit Testing is not static that once you have done and your job is complete, It will go on through out life of product until you do not stop further development on your product

Basically Unit Testing should be done each time : 1) you do a fix

2) New Release

3) Or you find a new Issue

I have not mentioned development period, as during this period your unit level test are evolved.

Basic thing here is not Quantity (How much) but coverage of your unit test

For example : For your application you fond a issue an particular function X, You do a
fix for X, If no other module is touched you can do unit testing
applicable for module X , Now this is point how much unit testing for X
cover

So Your unit Test must check:

1) Each interface

2) All input/out operations

3) Logical checks

4) Application specific results

Целью тестирования разработчика является ускорение разработки завершенных программное обеспечение приемлемого уровня качества.

Это приводит к двум предостережениям:

1. совершенно возможно сделать это неправильно, так что это действительно замедлит вашу работу. Так что, если вы обнаружите, что это замедляет вас, скорее всего, вы делаете это неправильно.
2. ваше определение «приемлемого качества» может отличаться от определения маркетинга. В конце концов, они правы или, по крайней мере, последнее слово за ними.

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

Автоматическое модульное тестирование приносит много пользы. Мы использовали его в нескольких проектах. Если кто-то сломает сборку, все сразу узнают, кто это сделал, и исправят. Он также встроен в более поздние версии Visual Studio. Посмотрите на

Test Driven Development

. Он должен сэкономить вам много времени и не вызвать значительных накладных расходов. Надеюсь это поможет! Если да, отметьте это.

For unit testing, my company has adopted a fairly good strategy: we have a tiered application (Data Layer, Service Layer/Business Objects, Presentation layer).

Our service layer is the ONLY way to interact with the database (via methods in the data layer).

Our goal is to have at least a basic unit test in place for each method in the service layer.

It's worked well for us - we don't always thoroughly check every code path (especially in complex methods) but every method has it's most common code path(s) verified.

Our objects are not unit tested, except incidentally via the service layer tests. They also tend to be 'dumb' objects - most have no methods except those required (such as Equals() and GetHastCode()).

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

Таким образом, не проверяйте все до смерти, но Рассмотрим некоторые общие случаи и несколько крайних случаев, чтобы посмотреть, что произойдет, если что-то пойдет не так, как планировалось изначально.

«Стоимость» оплачивается во время разработки, когда она намного более рентабельна, а возврат осуществляется во время текущего обслуживания, когда исправлять ошибки намного сложнее и дороже.

Обычно я всегда провожу модульное тестирование методов, которые:

• чтение / запись в хранилище данных,
• выполнение бизнес-логики и
• проверка ввода

Затем, для более сложных методов, я буду тестировать их. . Я не тестирую простые вещи, такие как методы получения / установки или простые математические вычисления.

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

I always believe in not being extreme. In particular when time and energy are limited. You just can't test it all.

Not every methods/functions need a unit test. The following might not need. (1) The one that is clearly not complex like just get/set, little condition or loop. (2) The one that will be called by other method that have unit tests.

With these two criteria, I think you can cut a lot of those.

Just a thought.

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

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

Конечно, полное покрытие - это хорошо в теории, но на практике часто в этом нет необходимости. Не говоря уже о том, что это слишком дорого.

Я думаю, это заблуждение:

Если вы протестируете каждый класс, каждый метод, ваш текущий выпуск займет больше времени, возможно, намного дольше.

Тестирование - особенно Test First - улучшает наш поток, удерживает нас в зоне, фактически ускоряет нас. Я выполняю работу быстрее, потому что я тестирую. Отсутствие тестирования замедляет нас.

Я не тестирую геттеры и сеттеры; Я думаю, что это бессмысленно - тем более, что они создаются автоматически. Но почти все остальное - это моя практика и мой совет.

Мне посоветовали следующее:

• Пробуйте, как думаете; Через некоторое время оцените себя:
• Если на тестирование тратится больше времени, чем вы считали разумным, и у вас была слишком малая отдача от инвестиций, тестируйте меньше.
• Если ваш продукт был протестирован достаточно, а вы потеряли время, протестируйте больше.
• Выполните цикл по мере необходимости.

Другой алгоритм:: -)

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

ОБНОВЛЕНО для комментария, о доказательстве полезности некоторых тестов (тех, в которые вы твердо верите):

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

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

• Там, где вы отслеживаете время, которое вы тратите, отметьте отдельно затраты , связанные с непроверенным кодом (если не доступны в инструменте, добавьте его в качестве комментария)
• Суммируйте эти затраты в специальном отчете, если инструмент не работает, чтобы каждую неделю ваш менеджер считал, что X% вашего времени было потрачено на это
• Каждый раз, когда вы оцениваете нагрузки, отдельно оцениваете несколько вариантов, с автоматическим тестированием или без него, , показывающее, что время, затрачиваемое на ручное или автоматическое тестирование , примерно одинаково (если вы ограничитесь наиболее полезными тестами, как объяснялось ранее), в то время как последнее является активом против регрессий.
• Свяжите ошибки с исходным кодом . Если ссылка отсутствует в вашем процессе, найдите способ связать их: вам нужно показать, что ошибка возникает из-за отсутствия автоматических тестов.
• Также соберите отчет об этих ссылках .

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

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

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

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

относительно мнения продавца о том, что тестирование не требуется - ну, если они так много знают, почему они не делают чертовски кодирование?

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

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

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

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