The problem is that the test has any logic at all. Conditionals and looping structures indicate the test is doing too much. Like jonsharpe said in a comment, this test needs to be split into at least two parameterized tests.

To promote this separation, create two different variables holding test data. One set is the "happy path" and the other set is for the "unhappy path". The advantage here is that you can give each test data variable a relevant name.

The more focused a test is, the easier it is to maintain as the application evolves. Rather than parameterize the warning tests, consider writing specific tests with a good name to verify each kind of warning. Data-driven tests are useful for boundary testing, where a range of values are valid and each value in the range has the same expected behavior.

Tests should verify only one behavior. As soon as they verify more than one behavior, the test has too many reasons to fail. Conditionals are an immediate sign the test has too many reasons to fail. Refactor the test into multiple tests and give each test a good name, and ideally a single assertion.

The problem is that the test has any logic at all. Conditionals and looping structures indicate the test is doing too much. Like jonsharpe said in a comment, this test needs to be split into at least two parameterized tests.

To promote this separation, create two different variables holding test data. One set is the "happy path" and the other set is for the "unhappy path". The advantage here is that you can give each test data variable a relevant name.

The more focused a test is, the easier it is to maintain as the application evolves. Rather than parameterize the warning tests, consider writing specific tests with a good name to verify each kind of warning. Data-driven tests are useful for boundary testing, where a range of values are valid and each value in the range has the same expected behavior.

Tests should verify only one behavior. As soon as they verify more than one behavior, the test has too many reasons to fail. Conditionals are an immediate sign the test has too many reasons to fail. Refactor the test into multiple tests and give each test a good name. Tests that make more than one assertion should be inspected to ensure the assertions are related to the behavior under test. Assertions unrelated to the behavior being tested should be refactored into their own tests.

The problem is that the test has any logic at all. Conditionals and looping structures indicate the test is doing too much. Like jonsharpe said in a comment, this test needs to be split into at least two parameterized tests.

To promote this separation, create two different variables holding test data. One set is the "happy path" and the other set is for the "unhappy path". The advantage here if that you can give each test data variable a relevant name.

The more focused a test is, the easier it is to maintain as the application evolves. Rather than parameterize the warning tests, consider writing specific tests with a good name to verify each kind of warning. Data-driven tests are useful for boundary testing, where a range of values are valid and each value in the range has the same expected behavior.

Tests should verify only one behavior. As soon as they verify more than one behavior, the test has too many reasons to fail. Conditionals are an immediate sign the test has too many reasons to fail. Refactor the test into multiple tests and give each test a good name, and ideally a single assertion.

The problem is that the test has any logic at all. Conditionals and looping structures indicate the test is doing too much. Like jonsharpe said in a comment, this test needs to be split into at least two parameterized tests.

To promote this separation, create two different variables holding test data. One set is the "happy path" and the other set is for the "unhappy path". The advantage here is that you can give each test data variable a relevant name.

The more focused a test is, the easier it is to maintain as the application evolves. Rather than parameterize the warning tests, consider writing specific tests with a good name to verify each kind of warning. Data-driven tests are useful for boundary testing, where a range of values are valid and each value in the range has the same expected behavior.

Tests should verify only one behavior. As soon as they verify more than one behavior, the test has too many reasons to fail. Conditionals are an immediate sign the test has too many reasons to fail. Refactor the test into multiple tests and give each test a good name, and ideally a single assertion.