Как я могу улучшить свои тесты junit

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

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

Обновление 1: Считайте следующее и полагайте, что получающийся дизайн позволит Вам на самом деле тестировать логику шифрования, не поражая файлы/базы данных - http://www.lostechies.com/blogs/gabrielschenker/archive/2009/01/30/the-dependency-inversion-principle.aspx (не в Java, но иллюстрирует проблему очень хорошо)..., также отмечают, что можно сделать действительно сфокусированные интеграционные тесты на читателей/устройства записи, вместо того, чтобы иметь необходимость протестировать все это вместе.

Я предлагаю:

• Постепенно включайте реальные модульные тесты в свою систему. Можно сделать это при выполнении изменений и разработке новых возможностей, рефакторинге соответственно.
• При выполнении предыдущего включайте сфокусированные интеграционные тесты в соответствующих случаях. Удостоверьтесь, что Вы можете выполнить модульные тесты, разделенные от интеграционных тестов.
• Полагайте, что Ваши тесты близко к тестированию системы в целом, таким образом отличаются от автоматизированных приемочных испытаний только в этом, они воздействуют на границу API. Учитывая это думают о факторах, связанных с важностью API для продукта (как то, если это будет использоваться внешне), и есть ли у Вас хорошее покрытие с автоматизированными приемочными испытаниями. Это может помочь Вам понять то, что является значением наличия их в Вашей системе, и также почему они естественно занимают много времени. Примите решение о том, будете ли Вы тестировать систему в целом на интерфейсном уровне или обоих interface+api уровень.

Обновление 2: На основе других ответов я хочу очистить что-то относительно выполнения TDD. Позволяет говорят, что необходимо проверить, посылает ли некоторая данная логика электронное письмо, регистрирует информацию о файле, сохраняет данные на базе данных и называет веб-сервис (не внезапно, я знаю, но Вы начинаете добавлять тесты для каждого из тех). На каждом тесте Вы не хотите поражать внешние системы, что Вы действительно хотите протестировать, то, если логика выполнит вызовы к тем системам, которые Вы ожидаете, что это сделает. Таким образом, то, когда Вы пишете тест, который проверяет, что электронное письмо послано, когда Вы создаете пользователя, что Вы тестируете, - то, если логика называет зависимость, которая делает это. Заметьте, что можно записать эти тесты и связанную логику, на самом деле не имея необходимость реализовать код, который посылает электронное письмо (и затем имеющий необходимость получить доступ к внешней системе для знания, что было отправлено...). Это поможет Вам сфокусироваться на задаче под рукой и помочь Вам получить отделенную систему. Это также сделает простым протестировать то, что отправляется в те системы.

Уменьшите зависимости между тестами. Это может быть сделано при помощи Насмешек. Martin Fowler говорит об этом в Насмешках, не тупики, особенно почему насмешка уменьшает зависимости между тестами.

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

@RunWith(JExample.class)
public class MyTest {

    @Test
    public Object a() { 
        return new Object();
    }

    @Test
    @Given("#a")
    public Object b(Object object) { 
        // do something with object
        return object; 
    }

    @Test
    @Given("#b")
    public void c(Object object) { 
        // do some more things with object
    }

}

Правовая оговорка, я среди разработчиков JExample.

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

Для знания, какие тесты хороши это помогает читать больше на BDD: http://dannorth.net/introducing-bdd http://techblog.daveastels.com/2005/07/05/a-new-look-at-test-driven-development/ http://jonkruger.com/blog/2008/07/25/why-behavior-driven-development-is-good/

Для улучшения теста, который Вы упомянули я разделю его на следующие три тестовых класса с ними имена метода тестирования и контекст:

Создание учетных записей пользователей

• Прежде чем пользователь создается
  • пользователь не существует
• Когда пользователь создается
  • пользователь существует
• Когда пользователь удален
  • пользователь больше не существует

Вход в систему

• Когда пользователь существует
  • пользователь может войти в систему с правильным паролем
  • пользователь не может войти в систему с неправильным паролем
• Когда пользователь не существует
  • пользователь не может войти в систему

Отправка сообщений

• Когда пользователь отправляет сообщение
  • сообщение появляется в ящике исходящих сообщений отправителя
  • сообщение появляется в ящике входящих сообщений reciever
  • сообщение не появляется ни в каких других окнах сообщения
• Когда сообщение удалено
  • сообщение больше не существует

Также необходимо улучшить скорость тестов. У Вас должен быть комплект модульного теста с хорошим покрытием, которое может работать через несколько секунд. Если займет больше времени, чем 10-20 секунд запустить тесты, то Вы будете смущаться выполнять их после каждого изменения, и Вы теряете часть быстрой обратной связи, которую запущение тестов дает Вам. (Если это говорит с базой данных, это не модульный тест, а тестирование системы или интеграционный тест, которые имеют их использование, но не достаточно быстры, чтобы выполняться постоянно.) Необходимо повредить зависимости классов под тестом путем насмешки или блокирования их. Также из Вашего описания кажется, что Ваши тесты не изолируются, но вместо этого тесты зависят от побочных эффектов, вызванных предыдущими тестами - это нет - нет. Хорошие тесты являются ПЕРВЫМИ.

При использовании TestNG, можно аннотировать тесты во множестве путей. Например, можно аннотировать тесты выше как продолжительные. Затем можно настроить automated-build/continuous сервер интеграции для выполнения их, но стандартная "интерактивная" сборка разработчика не была бы (если они явно не выбирают к).

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

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

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

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

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

Присоединитесь к списку рассылки, чтобы задать вопросы и просто считать трафик, проникающий. JUnit перечисляют в Yahoo (что-то как groups.yahoo.com/junit). Некоторые сильные мира сего в мире JUnit находятся в том списке и активно участвуют.

Получите список золотых правил модульных тестов и прикрепите их на Ваш (и другие) стена кабины, что-то как:

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

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

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

Таким образом, там следуют за опциями:

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

• Сделайте свои тесты большим количеством “модульного теста” - как. Поэтому необходимо будет разбить тесты и возможно изменить текущий производственный код. Почему? Поскольку цели поблочного тестирования при тестировании небольших единиц кода (пуристы поблочного тестирования предлагают только один класс сразу). Путем выполнения этого модульные тесты становятся более независимыми. При изменении поведения одного класса просто необходимо изменить относительно небольшой объем кода модульного теста. Это делает Ваш модульный тест более устойчивым. Во время того процесса Вы могли бы видеть, что Ваш текущий код не поддерживает поблочное тестирование очень хорошо - главным образом из-за зависимостей между классами. Это - причина, что необходимо будет также изменить производственный код.

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

• Удалите дублирование кода в своих тестах: Как в производственном коде устраняют дублирование кода и помещают код в классы помощника или вспомогательные методы. Если что-то изменяется, Вы, возможно, только должны были бы изменить вспомогательный метод или класс. Таким образом, Вы будете сходиться к следующему предложению.

• Добавьте другой слой косвенности к Вашим тестам: Произведите вспомогательные методы и классы помощника, которые воздействуют на более высокий уровень абстракции. Они должны действовать как API для Ваших тестов. Эти помощники называют Вас производственным кодом. Ваши тесты истории должны только позвонить тем помощникам. Если что-то изменяется, Вы должны изменить только одно место в своем API и не должны касаться всех Ваших тестов.

Подписи в качестве примера для Вашего API:

createUserAndDelete(string[] usersForCreation, string[] userForDeletion);
logonWithUser(string user);
sendAndCheckMessageBoxes(string fromUser, string toUser);

Для общего поблочного тестирования я предлагаю взглянуть в Тестовые Шаблоны XUnit от Gerard Meszaros.

Для повреждения зависимостей в Ваших производственных тестах взглянули в Работу Эффективно с Унаследованным кодом от Michael Feathers

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

Я лично использую профилировщика Netbeans, но существуют в других IDE и одинокие также.

Для покрытия кода я использую Cobertura, но работы EMMA также (EMMA имел раздражение, которое не имел Cobertura... Я забываю то, чем это было, и это не может больше быть проблема). Те два свободны, там заплачены также, которые хороши.