Как узнать, вызван ли вызов метода из тестового класса

Hii ... Есть ли способ узнать, вызван ли вызов метода из тестового класса? Если это из тестового класса ... тогда мне нужно инициализировать некоторые фиктивные значения для переменных в классе. Я хотел бы написать Test Class с минимальным изменением в исходном коде ... Класс следует за одноэлементным шаблоном. Так называется его частный конструктор, который вызывает некоторый код, который блокирует мое тестирование. Так что я должен позвонить фиктивные методы внутри в частном конструкторе так, что он работает гладко ..Как узнать, вызван ли вызов метода из тестового класса

В настоящее время я делаю это ...

StackTraceElement[] stack = new Throwable().getStackTrace(); 
boolean blnFrmTesting = false; 
for (StackTraceElement stackTraceElement : stack) { 
    if(null != stackTraceElement && null != stackTraceElement.getFileName() && stackTraceElement.getFileName().endsWith("Test.java")) { 
     blnFrmTesting = true; 
     break; 
    } 
} 
return blnFrmTesting;

Является ли это правильный метод ... Или там любой другой способ .. как проверка аннотации ... («@ Test»)

источник

2010-11-19 simplysiby

Ну, для технической части я предлагаю вам вместо этого попытаться выяснить, имеет ли класс имя класса Test, instaead of file name, которая (хотя Java-спецификация пытается ее нормализовать) всегда немного более нечеткая (например, о внутреннем классе).

Однако в более общем виде ваш код, кажется, игнорирует примерно десять лет разработки Java, игнорируя существование тестовых инфраструктур (JUniot, TestNG) и связанных с ними экосистем. В частности, чтобы определить «фиктивные значения», домен смеющихся фреймворков - это путь. Есть в настоящее время довольно много интересных альтернатив:

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

источник

2010-11-19 10:14:54 Riduidel

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

Я думаю, что точка Ридиделя заключается в том, что статическая инициализация очень сложна для проверки кода. Есть некоторые хакерские проблемы, но это приводит к тому, что тестовый тест тестирует нечто иное, чем производственный код, производственный код имеет функциональность, которая существует только для тестирования, или тестовый код, не предоставляющий полную и читаемую спецификацию. Рамки IoC и инъекция зависимости могут позволить гарантировать, что в течение всего срока службы вашего приложения есть только один экземпляр класса без статического глобального доступа или изменчивого статического состояния, что приводит к более тестируемому коду. – NamshubWriter

@NamshubWriter О, что Нил Стивенсон застенчивое имя пользователя! Очень нравится ! – Riduidel

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

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

источник

2010-11-19 10:39:46

+1 для инъекций. Если класс должен «знать» что-то вне себя, вставьте его. –

Я вообще согласен с Sudhir и не понимаю, что Riduidel хочет сказать, рекомендуя использовать Mocking. Mocking отлично, если вы хотите имитировать среду и окрестности класса.

Я думаю, что ваш метод в порядке. Вы можете действительно улучшить его, если добавить проверку аннотации @Test и факт, что класс расширяет TestCase. Если вы добавите поддержку JUniot и testNG, вы даже можете опубликовать свой код, и, возможно, другие люди смогут его использовать.

Но я думаю, что, возможно, вы даже можете упростить метод. Для этой цели я использовал специальное системное свойство. Как правило, мне приходилось идентифицировать, что код работает под сервером приложений, поэтому я использовал свойство, типичное для сервера приложений. Например, jboss.server.name для JBoss и catalina.base для Tomcat. Если JUnit не создает никакого специального свойства, вы можете сделать это самостоятельно в начале теста и проверить код.

источник

2010-11-19 11:03:29 AlexR

Как узнать, вызван ли вызов метода из тестового класса

ответ

Смежные вопросы