Тесты, “когда”, “что”, и “почему”?
Наилучший способ сделать это с помощью регулярных выражений:
List<String> list = new ArrayList<>();
list.add("One");
list.add("Two");
String str = "Iamstillquite/{Name}/newtoJava/programm/ingandIam/{subInterfaceId}/tryingtoupdate/anexisting";
String regex = "(?<=^[^\\{]+)\\{.*?\\}";
for (String s : list)
{
str = str.replaceAll(regex, s);
}
System.out.println(str);
Вывод:
Iamstillquite/One/newtoJava/programm/ingandIam/Two/tryingtoupdate/anexisting
Преимущества: Вам не придется менять ваших существующих данных, и регулярное выражение невероятно полезно для поиска и замены материала.
Кроме того, вы можете оставить входную строку str такой, какая она есть, в отличие от того, что вам придется делать для других ответов, приведенных здесь.
4 ответа
Я сказал бы, что, что Вы на самом деле тестируете, классы эквивалентности. По моему мнению, нет никакого различия между добавлением к списку, который имеет 3 объекта или 7 объектов. Однако существует различие между 0 объектами, 1 объектом и> 1 объект. У меня, вероятно, было бы 3 теста, каждый для Добавляет/Удаляет методы для этих случаев первоначально.
После того как ошибки начинают входить от QA/пользователей, я добавил бы каждый такой отчет об ошибках как тестовый сценарий; посмотрите, что ошибка воспроизводит путем получения красной панели; исправьте ошибку путем получения зеленой панели. Каждый такой 'обнаруживающий ошибку' тест устанавливается - это - моя система поддержки (чтение: регрессионный тест), что, даже если я делаю эту ошибку снова, у меня будет мгновенная обратная связь.
Думайте о своих тестах как о спецификации. Если Ваша система может повредить (или иметь существенные ошибки) без Вашего тестового сбоя, то у Вас нет достаточного тестового покрытия. Если одна единая точка отказа заставляет много тестов повреждаться, у Вас, вероятно, есть слишком много (или слишком сильно связываются).
Это действительно трудно определить объективным способом. Я предполагаю, что сказал бы, допускают ошибку на стороне тестирования слишком много. Затем, когда тесты начинают раздражать Вас, это - конкретные тесты для осуществления рефакторинг/повторно имения целью (потому что они являются слишком хрупкими, или тестируют неправильную вещь, и их отказы не полезны).
Несколько подсказок:
Каждый тестовый сценарий должен только протестировать одну вещь. Это означает, что структура тестового сценария должна быть "установкой", "выполните", "утверждайте". В Ваших примерах Вы смешиваете эти фазы. Попытайтесь разделить свои методы тестирования. Это помогает видеть точно, что Вы тестируете.
Попытайтесь дать Вашим методам тестирования имя, которое описывает то, что оно тестирует. Т.е. эти три тестовых сценария, содержавшиеся в Вашем ContainsItem (), становятся: containsReportsFalseIfTheItemHasNotBeenAdded (), containsReportsTrueIfTheItemHasBeenAdded (), containsReportsFalseIfTheItemHasBeenAddedThenRemoved (). Я нахожу, что принуждение меня придумать описательное имя как этот помогает мне осмыслять то, что я должен протестировать, прежде чем я кодирую фактический тест.
Если Вы делаете TDD, необходимо записать тестовые первые и только добавить код к реализации, когда у Вас есть провальный тест. Даже если Вы на самом деле не сделаете этого, то это даст Вам общее представление о том, сколько тесты достаточно. Кроме того, используйте инструмент покрытия. Для простого класса как контейнер необходимо стремиться к 100%-му покрытию.
_list экземпляр класса Вы записали? Если так, я сказал бы, что тестирование его разумно. Хотя в этом случае, почему Вы создаете пользовательский класс Списка?
Если это не код, Вы записали, не тестируйте его, если Вы не подозреваете, что это - в некотором роде багги.
Я пробую к тестовому коду, это является независимым и модульным. Если существует своего рода функция Бога в коде, я должен поддержать, я разделяю как можно больше его в подфункции и тестирую их независимо. Затем функция Бога может быть записана, чтобы быть, "очевидно, корректной" - никакие ответвления, никакая логика, просто передав результаты одной хорошо протестированной подфункции другому.