Интересный пример вычитала в книжке "Изучаем Java".
Есть задача - создаем массив с тремя последовательными числами от 0 до 7. Это типа кораблика из "морского боя". Пользователь вводит число от 0 до 7, мы проверяем - попал?
Если попал, то счетчик удачных попыток инкрементируется (увеличивается на 1).
Но в книжке учат сразу делать правильно - перед тем, как писать сам код, напиши тесты! И примерчик - если наш кораблик это "3, 4, 5", вводим "3" и ожидаем увидеть ответ "попал".
И каверзный вопросик - а какие еще тесты стоит написать? Мы к этому еще вернемся, но попробуйте подумать об этом сами...
Тут, разумеется, сомнений нет - тесты должны покрыть все ветки, все сообщения, не только "попал", но и "мимо" и "убил". А еще желательно проверить, что будет, если мы выйдем за границы от 0 до 7, введя корректное число (8, граничное значение) и введя некорректную комбинацию, буковками.
Тут начинаешь задумываться - а будет ли это рассматриваться в книге? Все-таки тестировщик внутри глаголет, что надо проверить все-все-все, но, может, для юнит-тестов хватит покрытия веток кода?
Поэтому переворачиваем страницу и читаем уже готовый код. Ага, да, тут пока еще никак исключения не обрабатываются... Но что это? В книжке указана еще одна ошибка.
Мы можем ввести три раза подряд любое правильное число, например, "3" и получим результат "убил". Ведь он просто завязан на счетчик удачных попыток, который не проверяет (пока) уникальность введенных данных.
Пример заставил меня задуматься... Потому что, увидев пример от авторов (только на одно сообщение из трех), я быстренько развила мысль на все сообщения, потом задумалась об эксепшенах - а будем ли мы их обрабатывать? Стала изучать реальный код игры и, глядя на пошагово расписанную программу, находила ее логичной. Пока не посмотрела на пример с тремя тройками.
А ведь забавно. Смотри я не на код, а на ТЗ, мысль проверить такой вариант пришла бы мне в голову гораздо быстрее. Но - все таки после проверки всех сообщений и всяких нехорошестей. Ведь это (проверяем все ветки ТЗ, все сообщения + выход за границы) первое, что приходит на ум. Это то, что проверить проще всего. А потом уже сидеть и медитировать, вспоминая техники тест-дизайна и продумывая, что тут можно проверить еще.
Но ведь это такой простой пример! Такая очевидная бага. Сразу понимаешь, почему разработчикам сложно писать юнит-тесты. Вот сформировалось у них в голове понимание того, как программа должна работать, как она должна себя вести. Написали они код, написали юнит-тесты. И смотрят на код и не видят порой очевидного...
Поэтому мы им и нужны
А вообще хотелось бы еще раз напомнить, что не стоит недооценивать простые комбинации. Если Вы уже проверили ввод положительных значений... Проверьте ввод тех же самых значений во второй и третий раз - кто знает, как поведет себя программа на нем?
Есть задача - создаем массив с тремя последовательными числами от 0 до 7. Это типа кораблика из "морского боя". Пользователь вводит число от 0 до 7, мы проверяем - попал?
Если попал, то счетчик удачных попыток инкрементируется (увеличивается на 1).
Но в книжке учат сразу делать правильно - перед тем, как писать сам код, напиши тесты! И примерчик - если наш кораблик это "3, 4, 5", вводим "3" и ожидаем увидеть ответ "попал".
И каверзный вопросик - а какие еще тесты стоит написать? Мы к этому еще вернемся, но попробуйте подумать об этом сами...
Тут, разумеется, сомнений нет - тесты должны покрыть все ветки, все сообщения, не только "попал", но и "мимо" и "убил". А еще желательно проверить, что будет, если мы выйдем за границы от 0 до 7, введя корректное число (8, граничное значение) и введя некорректную комбинацию, буковками.
Тут начинаешь задумываться - а будет ли это рассматриваться в книге? Все-таки тестировщик внутри глаголет, что надо проверить все-все-все, но, может, для юнит-тестов хватит покрытия веток кода?
Поэтому переворачиваем страницу и читаем уже готовый код. Ага, да, тут пока еще никак исключения не обрабатываются... Но что это? В книжке указана еще одна ошибка.
Мы можем ввести три раза подряд любое правильное число, например, "3" и получим результат "убил". Ведь он просто завязан на счетчик удачных попыток, который не проверяет (пока) уникальность введенных данных.
Пример заставил меня задуматься... Потому что, увидев пример от авторов (только на одно сообщение из трех), я быстренько развила мысль на все сообщения, потом задумалась об эксепшенах - а будем ли мы их обрабатывать? Стала изучать реальный код игры и, глядя на пошагово расписанную программу, находила ее логичной. Пока не посмотрела на пример с тремя тройками.
А ведь забавно. Смотри я не на код, а на ТЗ, мысль проверить такой вариант пришла бы мне в голову гораздо быстрее. Но - все таки после проверки всех сообщений и всяких нехорошестей. Ведь это (проверяем все ветки ТЗ, все сообщения + выход за границы) первое, что приходит на ум. Это то, что проверить проще всего. А потом уже сидеть и медитировать, вспоминая техники тест-дизайна и продумывая, что тут можно проверить еще.
Но ведь это такой простой пример! Такая очевидная бага. Сразу понимаешь, почему разработчикам сложно писать юнит-тесты. Вот сформировалось у них в голове понимание того, как программа должна работать, как она должна себя вести. Написали они код, написали юнит-тесты. И смотрят на код и не видят порой очевидного...
Поэтому мы им и нужны
А вообще хотелось бы еще раз напомнить, что не стоит недооценивать простые комбинации. Если Вы уже проверили ввод положительных значений... Проверьте ввод тех же самых значений во второй и третий раз - кто знает, как поведет себя программа на нем?
Комментариев нет:
Отправить комментарий