Убедитесь, что все методы getter были вызваны в тесте JUnit

У меня есть класс, который использует XStream и используется в качестве формата передачи для моего приложения. Я пишу тесты для других классов, которые сопоставляют этот формат передачи с другим стандартом обмена сообщениями. Я хотел бы убедиться, что все геттеры в моем классе вызываются в тесте, чтобы убедиться, что при добавлении нового поля мой тест правильно проверяет его.Убедитесь, что все методы getter были вызваны в тесте JUnit

Грубый набросок класса XStream

@XStreamAlias("thing") 
public class Thing implements Serializable { 
private int id; 
private int someField; 

public int getId(){ ... } 
public int someField() { ... } 
}

Так что теперь, если я обновлю этот класс будет:

@XStreamAlias("thing") 
public class Thing implements Serializable { 
private int id; 
private int someField; 
private String newField; 

public int getId(){ ... } 
public int getSomeField() { ... } 
public String getNewField(){ ... } 
}

Я хочу, чтобы мой тест на неудачу, потому что старые тесты не вызывая getNewField() ,

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

В идеале это будет полностью содержаться в тесте и не требует модификации базового класса Thing.

Любые идеи? Спасибо, что посмотрели!

источник

2010-04-01 Freiheit

Простой. Не проверяйте методы получения. Они «слишком просты» для тестирования. – Pyrolistical

Может быть, инструменты для покрытия кода - это то, что вам нужно. Если у вас 100% -ый охват кода, все методы get были вызваны. Если вы используете eclipse, проверьте плагин EclEmma.

источник

2010-04-01 18:28:30

Crap. Мне нужен значок «глупый шлем» от StackOverflow. У меня установлена Эмма, и я использую ее в других проектах. Спасибо за напоминание Ха. – Freiheit

Вы можете использовать Sonar. Я считаю, что это очень полезно и легко настроить. Также легко интегрируется с hudson. У них также есть затмение plugin.

источник

2010-04-01 18:36:41 CoolBeans

Если вы хотите проверить свои тесты автоматически, чем JUnit, это не очень хороший вариант. Как вы хотите, чтобы ваш «специальный тест» всегда вызывался последним после всех других тестов? (Я не говорю, что это невозможно, но это касается модели/философии JUnit, согласно которой тестовые случаи должны быть независимыми друг от друга).

Если вы решите сделать это, одна из возможностей заключается в создании отчета о покрытии кода Cobertura и анализе его, чтобы определить, были ли охвачены все геттеры во время тестов. Возможно, существует также способ взаимодействовать с Cobertura через некоторый API, а не в зависимости от файлов выходных отчетов.

Пример алгоритма:

запустить регулярный набор тестов
запустить Cobertura
запустить специальный тест

источник

2010-04-01 18:41:24 kopper

Это звучит, как вы говорите о мета-тест - тест контрольная работа. ИМХО это не имеет большого смысла. Тест - это спецификация. Поэтому разработчик тестового примера должен обновлять тест, добавляя новые поля. Тем не менее, вот способ гетто назвать все методы getter Java-компонента.

public class GhettoBeanTest { 
    private static class Subclass extends SomeObject { 
     @Override public String toString() { 
      return org.apache.commons.lang.builder.ToStringBuilder.reflectionToString(this); 
     } 
    } 

    @Test public void ensureToStringMethodExecutes() { 
     String value = new Subclass().toString(); 

     // teset passed - all getter methods were executed by the toString method above 
    } 
}

источник

2010-04-01 18:53:22 les2