Есть ли такая вещь как слишком много поблочного тестирования?

Is there such as thing as too much unit testing?

Sure. The problem is finding the right balance between enough unit testing to cover the important areas of functionality, and focusing effort on creating new value for your customers in the terms of system functionality.

Unit testing code vs. leaving code uncovered by tests both have a cost.

The cost of excluding code from unit testing may include (but aren't limited to):

• Increased development time due to fixing issues you can't automatically test
• Fixing problems discovered during QA testing
• Fixing problems discovered when the code reaches your customers
• Loss of revenue due to customer dissatisfaction with defects that made it through testing

The costs of writing a unit test include (but aren't limited to):

• Writing the original unit test
• Maintaining the unit test as your system evolves
• Refining the unit test to cover more conditions as you discover them in testing or production
• Refactoring unit tests as the underlying code under test is refactored
• Lost revenue when it takes longer for you application to reach enter the market
• The opportunity cost of implementing features that could drive sales

You have to make your best judgement about what these costs are likely to be, and what your tolerance is for absorbing such costs.

In general, unit testing costs are mostly absorbed during the development phase of a system - and somewhat during it's maintenance. If you spend too much time writing unit tests you may miss a valuable window of opportunity to get your product to market. This could cost you sales or even long-term revenue if you operate in a competitive industry.

The cost of defects is absorbed during the entire lifetime of your system in production - up until the point the defect is corrected. And potentially, even beyond that, if they defect is significant enough that it affects your company's reputation or market position.

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

Наиболее очевидным случаем является пользовательский интерфейс. Что делает пользовательский интерфейс красивым, так это то, что трудно протестировать, а использование основного примера имеет тенденцию быть хрупким. Таким образом, уровень пользовательского интерфейса, связанный с внешним видом чего-либо, обычно не тестируется.

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

Для HTML я имел обыкновение проверять наличие необходимых данных (используя запросы XPath), но не тестировал весь HTML. Аналогично для XSLT и XML. В JavaScript, когда я мог, я тестировал библиотеки, но оставлял главную страницу в покое (за исключением того, что я переместил большую часть кода в библиотеки). Если JavaScript особенно сложен, я бы протестировал больше. Для баз данных я бы посмотрел на тестирование хранимых процедур и, возможно, представлений; остальное более декларативно.

Однако в вашем случае сначала начните с того, что беспокоит вас больше всего или вот-вот изменится, особенно если это не так уж сложно протестировать. Дополнительную помощь можно найти в книге Эффективная работа с устаревшим кодом .

Однако в вашем случае сначала начните с того, что беспокоит вас больше всего или вот-вот изменится, особенно если это не так уж сложно протестировать. Дополнительную помощь можно найти в книге Эффективная работа с устаревшим кодом .

Однако в вашем случае сначала начните с того, что беспокоит вас больше всего или вот-вот изменится, особенно если это не так уж сложно протестировать. Дополнительную помощь можно найти в книге Эффективная работа с устаревшим кодом .

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

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

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

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

As EJD said, you can't verify the absence of errors.

This means there are always more tests you could write. Any of these could be useful.

What you need to understand is that unit-testing (and other types of automated testing you use for development purposes) can help with development, but should never be viewed as a replacement for formal QA.

Some tests are much more valuable than others.

There are parts of your code that change a lot more frequently, are more prone to break, etc. These are the most economical tests.

You need to balance out the amount of testing you agree to take on as a developer. You can easily overburden yourself with unmaintainable tests. IMO, unmaintainable tests are worse than no tests because they:

1. Turn others off from trying to maintain a test suite or write new tests.
2. Detract from you adding new, meaningful functionality. If automated testing is not a net-positive result, you should ditch it like other engineering practices.

What should I test?

Test the "Happy Path" - this ensures that you get interactions right, and that things are wired together properly. But you don't adequately test a bridge by driving down it on a sunny day with no traffic.

Pragmatic Unit Testing recommends you use Right-BICEP to figure out what to test. "Right" for the happy path, then Boundary conditions, check any Inverse relationships, use another method (if it exists) to Cross-check results, force Error conditions, and finally take into account any Performance considerations that should be verified. I'd say if you are thinking about tests to write in this way, you're most likely figure out how to get to an adequate level of testing. You'll be able to figure out which ones are more useful and when. See the book for much more info.

Test at the right level

As others have mentioned, unit tests are not the only way to write automated tests. Other types of frameworks may be built off of unit tests, but provide mechanisms to do package level, system or integration tests. The best bang for the buck may be at a higher level, and just using unit testing to verify a single component's happy path.

Don't be discouraged

I'm painting a more grim picture here than I expect most developers will find in reality. The bottom line is that you make a commitment to learn how to write tests and write them well. But don't let fear of the unknown scare you into not writing any tests. Unlike production code, tests can be ditched and rewritten without many adverse effects.

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

В ситуации, не связанной с TDD, автоматические тесты должны проверять каждую строку кода, который вы пишете (в частности, покрытие Branch хорошее), но даже в этом случае есть исключения - вы не должны ' • Тестировать платформу или код фреймворка поставщика, если вы не знаете наверняка, что на этой платформе есть ошибки, которые могут повлиять на вас. Вам не следует тестировать тонкие обертки (или, в равной степени, если вам нужно это проверить, оболочка не тонкая). Вы должны тестировать всю основную бизнес-логику, и, безусловно, полезно иметь некоторый набор тестов, которые проверяют вашу базу данных на некотором элементарном уровне, хотя эти тесты никогда не будут работать в обычной ситуации, когда модульные тесты запускаются каждый раз при компиляции.

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

Чтобы узнать больше об этом, я бы посоветовал прочитать «Охват кода». Если вам это интересно, доступно множество материалов.

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

Кент Бек из JUnit и JUnitMax fame ответил на аналогичный мой вопрос . У вопроса немного другая семантика, но ответ определенно актуален

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

Например, если вам была предоставлена ​​библиотека с функцией добавления, вы не должны тестировать, что add (1,2) возвращает 3. Теперь, если вы НАПИСАЛ этот код, тогда да, вам следует его тестировать.

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

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

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

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

Когда вы тестировали свои модульные тесты, думая, что вы обеспечили 200% покрытие.