Как легко проверить код?

Question

Я изучаю Java, читая «Head First Java» и выполняя все головоломки и упражнения.В книге они рекомендуют писать классы TestDrive для тестирования написанного мной кода и предложений, это очень простая вещь, но, делая это, я думаю, что не могу полностью протестировать свой код, потому что я пишу тестовый кодзная, что я хочу получить, я не знаю, имеет ли это какой-то смысл, но мне было интересно, есть ли какой-нибудь способ тестирования моего кода простым способом, который говорит мне, что работает неправильно.Спасибо.

Answer 1

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

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

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

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

Так работает программное обеспечение и, возможно, причина того, что оно так и не закончилось.

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

и: Взятие Дилберта на тестирование .

Answer 2

Что мы подразумеваем под кодом?При модульном тестировании, о котором я думаю, мы говорим здесь, мы тестируем определенные методы и классы.

Я думаю, что не могу полностью протестировать свой код, потому что пишу тесткод, зная, что я хочу получить

Другими словами, вы исследуете, выполняет ли какой-то код контракт.Рассмотрим пример:

 int getInvestvalue( int depositCents, double annualInterestRate, int years) {

 }

Какие тесты вы можете разработать?Если вы разработаете хороший набор тестов, вы можете быть уверены в этом.Таким образом, мы могли бы попробовать следующие виды ввода:

  deposit 100, rate 5.0, years 1 : expected answer 105
  deposit 100, rate 0, years 1 : expected answer 100
  deposit 100, rate 10, years 0 : expected anwer 100

Что еще?Как насчет отрицательной ставки?

Что еще интереснее, как насчет очень высокой процентной ставки, такой как 1 000 000.50 и 100 000 лет, что произойдет с результатом, будет ли оно соответствовать целому числу? Суть разработки этого теста состоит в том, что он бросает вызов интерфейсу - почемунет ли документально подтвержденных исключений?

Тогда возникает вопрос: как нам определить эти тесты?Я не думаю, что есть единый подход, который приводит к созданию комплексного набора, но вот несколько вещей, которые следует учитывать:

1. Края: ноль, один, два, много.В моем примере мы не просто делаем ставку 5%.Мы рассматриваем особенно частные случаи.Ноль особенный, один особенный, отрицательный особенный, большое число особенное ...
2. Угловые случаи: комбинации ребер.В моем примере это большой показатель и большое количество лет.Выбор их является чем-то вроде искусства, и ему помогают наши знания о реализации: здесь мы знаем, что существует эффект «множителя» между показателями и годами.
3. Белая коробка: использование знания реализации для управления кодомохват.Регулировка входов, чтобы заставить код двигаться по отдельным путям.Например, если вы знаете, что в коде есть условный путь «если отрицательный коэффициент», то это ключ к включению теста отрицательного показателя.

Answer 3

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

Как только ваш код написан так, чтобы вы могли предвидеть ситуации, которые могут возникнуть на основе ваших зависимостей и входных параметров, вы должны написать тесты, ищущие правильное поведение из множества этих предсказуемых ситуаций. Одно из самых больших преимуществ, которые я обнаружил в модульном тестировании, заключается в том, что оно заставило меня задуматься: «А что если ...» и выяснить, как правильно будет вести себя в каждом случае? Например, я должен решить, имеет ли смысл выдавать исключение или возвращать нулевое значение в случае определенных ошибок.

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

Answer 4

На этом сайте много справочных ресурсов для тестирования кодов. SoftwareTestingHelp

Answer 5

Один из принципов «Test Driven Development» - это сначала написать тест (т.е. до того, как вы написали код). Очевидно, что этот тест изначально не удастся (ваша программа может даже не скомпилироваться). Если тест не не пройден, то вы знаете, что возникла проблема с самим тестом. Как только тест не пройден, цель состоит в том, чтобы продолжать писать код до тех пор, пока тест не пройдет.

Кроме того, некоторые из более популярных платформ модульного тестирования, такие как jUnit, позволят вам проверить, работает ли что-то или явно не работает (то есть вы можете утверждать, что генерируется исключение определенного типа). Это становится полезным для проверки неправильного ввода, угловых случаев и т. Д.

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

Answer 6

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

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

Программирование пар - еще один отличный способ предотвратить и устранить ошибки в вашем коде. Два ума лучше, чем один, и часто кто-то другой будет думать о том, чего ты не сделал (и наоборот).

Answer 7

TestDrive

Нет, вы должны писать JUnit или TestNG тесты.