Testng: @Test (enabled = false) аннотация на уровне класса должна отключать все методы в классе

Привет, Николас,

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

Имеет ли это смысл?

Да, спасибо, Седрик.

Я делаю неправильное предположение, что аннотация @test (enabled = false) в классе полностью исключает класс из выполнения

Я согласен, что это немного противоречит интуиции, но, к сожалению, уже поздно что-то менять ...

Привет, Седрик!
А как насчет добавления нового параметра в аннотацию @Test, называть его как-то вроде «enabledClass» и делать его истинным по умолчанию? Его следует использовать только на уровне класса (enabledClass = false) для отключения всего класса независимо от аннотаций на уровне метода и игнорировать, если он добавлен для метода.
Таким образом мы сохраним обратную совместимость и в то же время предоставим довольно полезную функциональность.
Если хотите, я могу реализовать это сам и предоставить запрос на перенос.
Заранее спасибо!

@ andronix83 ,

Боюсь, теперь это еще больше сбивает с толку, когда вам нужно объяснить тонкую разницу между enabled и enabledClass .

Текущее поведение enabled не самое интуитивно понятное, но в целом оно не кажется проблемой, если судить по тому, сколько раз эта проблема поднималась (почти никогда).

Привет, Седрик,

Я столкнулся с этой проблемой совсем недавно, на прошлой неделе. Я работаю над веб-сервером, который полагается на API-интерфейс Facebook Graph. У меня был тестовый класс, в котором некоторые методы тестирования полагались на код, обращающийся к Graph API, а другие методы тестирования вообще не нуждались в этой службе. Затем произошел глобальный сбой в работе Facebook в целом более чем на час. Это привело к сбою некоторых тестов в этом классе.

То, что я надеялся сделать, чтобы остальная часть моей команды разработчиков была разблокирована, - это просто немедленно отключить все тесты в этом классе с помощью аннотации @Test (enabled = false) на уровне класса. Конечно, это не сработало. Вместо этого мне приходилось по одному отключать каждый метод тестирования с ошибкой, что отнимало у меня больше времени, чем хотелось бы, или даже это было необходимо для решения этой проблемы.

В идеале TestNG поддерживает какую-то функциональность, аналогичную аннотации @Ignore в JUnit: http://junit.sourceforge.net/javadoc/org/junit/Ignore.html. Короче говоря, разработчикам действительно нужна эта функциональность.

Спасибо.

@ecbrodie Это уже поддерживается (попробуйте!), но есть предостережение: каждый отдельный метод, имеющий аннотацию @Test , повторно включит тест.

@Test(enabled = false)
public class T {
  void f() {} // will not run
}

@Test(enabled = false)
public class T {
  <strong i="10">@Test</strong>
  void f() {} // WILL run!
}

Это связано с семантикой, которая атрибуты на уровне метода переопределяют атрибуты, определенные на уровне класса, поэтому аннотация уровня метода @Test в основном говорит @Test(enabled = true) поскольку это значение по умолчанию ...

Имеет смысл?

Привет @cbeust , спасибо за этот пример, но это уже было понимание проблемы, поэтому я думаю, что вы, возможно, неправильно меня поняли. Тот момент, который я пытался сделать, был, учитывая текущую семантику @Test (enabled = true / false) и желание иметь способ действительно указать переопределение enabled на уровне класса, чтобы игнорировать все, что установлено в методе уровень, возможно, пришло время пересмотреть свою позицию против добавления какого-либо значения аннотации enabledClass .

Похоже, вы демонстрируете некоторое пренебрежение исходным подходом, который вы использовали с семантикой @Test (enabled). Если это действительно так, то почему бы не применить его семантику к чему-то, что, по вашему мнению, является более интуитивным?

Согласен, я думаю, что @Test(enabledClass = false) будет иметь смысл, и это единственный способ реализовать ваше предложение без нарушения обратной совместимости. Это тоже должно быть довольно легко.

Может быть, вам или @juherr будет интересно подать PR?

Я плохо себя чувствую. Мне не нравится идея добавить новый атрибут, который будет использоваться только в классе.
Тогда я думаю, что enable=false - плохая практика при использовании в исходном коде, потому что вам придется изменять источники, когда вы хотите запускать тесты.
IMO, если вы хотите отменить выбор класса, вместо этого следует использовать testng.xml .
@ecbrodie Как вы проводите тесты?

Кстати, я предлагаю вместо этого предоставить реализацию IAnnotationTransformer которая переопределит поведение по умолчанию enable=false в классе.
IAnnotationTransformer имеет только enable=false каждый тест, имеет ли их класс enable=false .
Это не нарушит обратную совместимость и не добавит конкретный параметр.
@cbeust Что ты думаешь?

@juherr Классный пиар, это действительно очень просто сделать с помощью IAnnotationTransformer .

Меня беспокоит только то, что для пользователя это немного более загадочно, чем использование атрибута enabledClass .

Обратите внимание, что у нас уже есть несколько атрибутов, которые применимы только на уровне класса ( suiteName , testName ).

Как я уже сказал, мне не нравится вариант использования. И я полагаю, этого хватит только на 2 человека, которые задавали его за последние 4 года :)

@juherr Достаточно

@ecbrodie Что вы думаете о пиаре?

https://github.com/cbeust/testng/pull/816

@cbeust
Просто любопытно. Что, если бы мы предоставили встроенный AnnotationTransformer, который может это сделать?

Да, это то, что предлагает # 816

@juherr
Спасибо, что поделились этой PR-информацией. Есть ли причина, по которой это ожидает слияния?

Что делать, если у меня есть сценарий, как показано ниже:

@Test(groups = { "regression", "smoke" }, dependsOnGroups = { "Creation" })
public class EditName {

    @Test(dataProvider="SomeTestData",dataProviderClass=SearchData.class)
    public void TC_1(String Msg) throws Exception{
        System.out.println(Msg);
    }

    @Test(dataProvider="SomeTestData",dataProviderClass=SearchData.class, dependsOnMethods = { "TC_1" }))
    public void TC_2(String Msg) throws Exception{
        System.out.println(Msg);
    }
}

1. Будут ли TC_1 и TC_2 принадлежать как к регрессионной, так и к дымовой группе?
2. Будут ли TC_1 и TC_2 зависеть от группы «Creation»?
3. Будет ли TC_2 зависеть от группы «Creation», а также от TC_1 или только от TC_1?

@ Rameshwar-Juptimath Какая связь между вашим образцом и этой проблемой?

Из-за этого неинтуитивного поведения @Test на уровне класса и метода.
Что следует порекомендовать как лучшую практику?
Стоит ли избегать использования обоих в тестах?
Поскольку мы более или менее используем его на уровне метода, чтобы иметь разные поставщики данных для каждого случая, мы должны избегать его в классе?
Мысли?

@aliciatang Поведение одинаково для всех атрибутов аннотации: значения в методе переопределяют значения в классе.

Начиная с 6.13 вы можете использовать @Ignore поведение которого вы ожидаете. Документацию для @Ignore можно найти здесь