Измените приватный член на по умолчанию для тестирования

Question

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

РЕДАКТИРОВАТЬ: Все вы, ребята, говорите правду. Но у классов часто есть вспомогательные закрытые методы. И эти методы могут быть сложными , поэтому их необходимо проверить. И это очень плохо - проверить общедоступные методы на предмет корректной работы частных сложных методов. Вам так не кажется?

Answer 1

Я обычно предпочитаю писать свои классы и тесты так, чтобы их было целесообразно писать с использованием открытого API.Поэтому в основном я говорю, что если вам нужен доступ к закрытому состоянию тестируемого класса, вы, вероятно, уже слишком вовлечены во внутреннее пространство этого класса с помощью своего теста.

Answer 2

Нет, это не так. Поскольку изменение тестового объекта может изменить результат. Если вам действительно нужно вызывать закрытые члены или методы во время теста, безопаснее добавить средство доступа. Это все еще меняет класс, но с меньшим риском. Пример:

private void method() { /* ... */ }

// For testing purpose only, remove for production
@Deprecated  // just another way to create awareness ;)
void testMethod() {
   method();
}

---

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

Предполагая, что имеем:

public class SomeClass {
  private Object helper(String s, String t) { /* ... +/ }
}

тогда мы можем проверить это как

@Test public void testHelper() {
   try {
     SomeClass some = new SomeClass();
     Method helperMethod = some.getClass().getDeclaredMethod("helper", String.class, String,class);
     helperMethod.setAccessible(true);
     Object result = helperMethod.invoke(some, "s", "t");
     // do some assert...

   catch(Exception e) {
     // TODO - proper exception handling
   }
}

Answer 3

Тестирование превосходит модификаторы конфиденциальности. Действительно, как часто ошибка возникает из-за «слишком большой» видимости метода? По сравнению с ошибками, вызванными методом, который не был полностью протестирован?

Было бы неплохо, если бы у Java была опция "друг", например, C ++. Но ограничение языка никогда не должно быть оправданием для того, чтобы что-то не тестировать.

Майкл Фезерс присоединяется к этой дискуссии в «Эффективной работе с устаревшим кодом» (отличная книга) и предполагает, что это может быть запах подкласса, который хочет быть извлеченным (и иметь публичные методы).

В нашем магазине (~ 1M LOC) мы заменяем 'private' на '/ TestScope /' в качестве индикатора того, что метод должен быть эффективно закрытым, но все же тестируемым.

Попытка обойти "личное" с помощью отражения - это ИМХО запах. Это затрудняет написание, чтение и отладку тестов, чтобы сохранить «фетиш» конфиденциальности, над которым вы все равно работаете. Зачем?

Answer 4

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

   MainObject.cs
    class MainObject
    {
        protected int MethodOne();    // Should have been private.
        ....
    }
    TestMainObject.cs
    class ExposeMainObject : MainObject
    {
        public int MethodOne();
    }
    class TestMainObject
    {
        public void TestOne()
        {
        }
    }

Поскольку тестовые объекты не поставляются, я не вижу проблем с этим, но если есть, пожалуйста, сообщите мне.