[T]ests
“A program that has not been tested is not working.”
― Bjarne Stroustrup
How many tests should be in a test suite? Unfortunately, the metric many programmers use is “That seems like enough.” A test suite should test everything that could possibly break. The tests are insufficient so long as there are conditions that have not been explored by the tests or calculations that have not been validated.
[T01]: Нехватка тестов
Сколько тестов должен включать тестовый пакет? К сожалению, многие программисты руководствуются принципом «Пожалуй, этого хватит». Тестовый пакет должен тестировать все, что может сломаться. Если в системе остались условия, не проверенные тестами, или вычисления, правильность которых не подтверждена, значит, количество тестов недостаточно.
[T01]: Нестача тестів
Скільки тестів має містити тестовий пакет? На жаль, багато програмістів керуються принципом «Мабуть цього вистачить». Тестовий пакет має тестувати все, що може зламатися. Якщо в системі залишилися умови, не перевірені тестами, або обчислення, правильність яких не підтверджена, то кількість тестів недостатня.
Coverage tools reports gaps in your testing strategy. They make it easy to find modules, classes, and functions that are insufficiently tested. Most IDEs give you a visual indication, marking lines that are covered in green and those that are uncovered in red. This makes it quick and easy to find if or catch statements whose bodies haven’t been checked.
[T02]: Используйте средства анализа покрытия кода
Средства анализа покрытия сообщают о пробелах в вашей стратегии тестирования. Они упрощают поиск модулей, классов и функций с недостаточно полным тестированием. Во многих IDE используются визуальные обозначения: строки, покрытые тестами, выделяются зеленым цветом, а непокрытые — красным. Это позволяет легко и быстро обнаружить команды if или catch, тело которых не проверяется тестами.
[T02]: Використовуйте засоби аналізу покриття коду
Засоби аналізу покриття повідомляють про прогалини у вашій стратегії тестування. Вони спрощують пошук модулів, класів та функцій з недостатньо повним тестуванням. Багато IDE використовують візуальні позначення: рядки, вкриті тестами, виділяються зеленим кольором, а непокриті — червоним. Це дозволяє легко та швидко виявити команди if або catch, тіло яких не перевіряється тестами.
They are easy to write and their documentary value is higher than the cost to produce them.
[T03]: Не пропускайте тривиальные тесты
Тривиальные тесты пишутся легко, а их информативная ценность превышает затраты времени на их создание.
[T03]: Не пропускайте тривіальні тести
Тривіальні тести пишуться легко, а їхня інформативна цінність перевищує витрати часу з їхньої створення.
Sometimes we are uncertain about a behavioral detail because the requirements are unclear. We can express our question about the requirements as a test that is commented out, or as a test that annotated with @Ignore. Which you choose depends upon whether the ambiguity is about something that would compile or not.
[T04]: Отключенный тест как вопрос
Иногда мы не уверены в подробностях поведения системы, потому что неясны сами требования к программе. Вопрос о требованиях можно выразить в виде теста — закомментированного или помеченного аннотацией @Ignore. Выбор зависит от того, компилируется или нет код, к которому относится неопределенность.
[T04]: Вимкнений тест як питання
Іноді ми не впевнені у подробицях поведінки системи, тому що неясні самі вимоги до програми. Питання про вимоги можна висловити у вигляді тесту — закоментованого або позначеного інструкцією @Ignore. Вибір залежить від того, чи компілюється код, до якого належить невизначеність.
Take special care to test boundary conditions. We often get the middle of an algorithm right but misjudge the boundaries.
[T05]: Тестируйте граничные условия
Особенно тщательно тестируйте граничные условия. Программисты часто правильно реализуют основную часть алгоритма, забывая о граничных ситуациях.
[T05]: Тестуйте граничні умови
Особливо ретельно тестуйте граничні умови. Програмісти часто правильно реалізують основну частину алгоритму, забуваючи про граничні ситуації.
Bugs tend to congregate. When you find a bug in a function, it is wise to do an exhaustive test of that function. You’ll probably find that the bug was not alone.
[T06]: Тщательно тестируйте код рядом с ошибками
Ошибки часто собираются группами. Если вы обнаружили ошибку в функции, особенно тщательно протестируйте эту функцию. Может оказаться, что ошибка была не одна.
[T06]: Ретельно тестуйте код поруч із помилками
Помилки часто збираються групами. Якщо ви виявили помилку у функції, особливо ретельно протестуйте цю функцію. Може виявитись, що помилка була не одна.
Sometimes you can diagnose a problem by finding patterns in the way the test cases fail. This is another argument for making the test cases as complete as possible. Complete test cases, ordered in a reasonable way, expose patterns.
As a simple example, suppose you noticed that all tests with an input larger than five characters failed? Or what if any test that passed a negative number into the second argument of a function failed? Sometimes just seeing the pattern of red and green on the test report is enough to spark the “Aha!” that leads to the solution.
[T07]: Закономерности сбоев часто несут полезную информацию
Иногда анализ закономерностей в сбоях тестовых сценариев помогает выявить причины возникших проблем. Это еще один аргумент в пользу максимальной полноты тестовых сценариев. Всесторонние наборы тестовых сценариев, упорядоченные логичным образом, выявляют закономерности.
Простой пример: вы заметили, что все тесты с входными данными, длина которых превышает пять символов, завершаются неудачей? Или что любой тест, который передает во втором аргументе функции отрицательное число, не проходит? Иногда простая закономерность чередования красного и зеленого в тестовом отчете заставляет нас воскликнуть «Ага!» на пути к правильному решению.
[T07]: Закономірності збоїв часто несуть корисну інформацію
Іноді аналіз закономірностей у збоях тестових сценаріїв допомагає виявити причини проблем. Це ще один аргумент на користь максимальної повноти тестових сценаріїв. Всебічні набори тестових сценаріїв, упорядковані логічно, виявляють закономірності.
Простий приклад: ви помітили, що всі тести із вхідними даними, довжина яких перевищує п'ять символів, завершуються невдачею? Чи будь-який тест, який передає у другому аргументі функції негативне число, не проходить? Іноді проста закономірність чергування червоного та зеленого у тестовому звіті змушує нас вигукнути «Ага!» на шляху до правильного рішення.
Looking at the code that is or is not executed by the passing tests gives clues to why the failing tests fail.
[T08]: Закономерности покрытия кода часто несут полезную информацию
Анализ того, какой код выполняется или не выполняется в ходе тестирования, иногда подсказывает причины возможных сбоев в ходе тестирования.
[T08]: Закономірності покриття коду часто несуть корисну інформацію
Аналіз того, який код виконується або не виконується в ході тестування, іноді нагадує причини можливих збоїв в ході тестування.
A slow test is a test that won’t get run. When things get tight, it’s the slow tests that will be dropped from the suite. So do what you must to keep your tests fast.
[T09]: Тесты должны работать быстро
Медленный тест не выполняется за разумное время. Если время поджимает, из тестового пакета первыми будут удалены медленные тесты. Сделайте все необходимое для того, чтобы ваши тесты работали быстро.
[T09]: Тести повинні працювати швидко
Повільний тест не виконується за розумний час. Якщо час стискає, з тестового пакета першими будуть видалені повільні тести. Зробіть все необхідне, щоб ваші тести працювали швидко.