For example, a test case named ExampleTest
ExampleTest {
testA{};
testB{};
testC();
}
I could run all this class with TestSuite.addTestSuite(ExampleTest.class);
but, how to select testA and testB run into TestSuite?
2 Ideas:
See if it makes sense to split ExampleTest into 2 test classes based on your partition
Otherwise use Categories to tag your tests and then run tests which belong to a specific category. Its simpler in NUnit, JUnit seems to require you to create an empty/ marker interface to get this done. A sample link with code.
Related
Best way of handling many test cases needing to navigate to a particular place before they run their asserts? For example a process has 5 steps and a test case needs to test a part of step 5, how can I set it up? Call the test case methods of the previous steps inside this test case, and do that for all test cases that test step 5?
Similarly, if a test case goes deep into the website - through many pages - should that navigation be re-written for every test case, or just call some test that already does that?
Any tips on this situations?
Best way of handling many test cases needing to navigate to a particular place before they run their asserts? For example a process has 5 steps and a test case needs to test a part
of step 5, how can I set it up?
I would create a Transporter class / pattern that the test case can call to get to that state. That will make the navigation code reusable to other tests and not make the test too big/complicated. You can also use the setUp() methods in your xUnit testing frameworks which will be called before each test and place the navigator code there, if you need to use it for other tests.
Similarly, if a test case goes deep into the website - through many
pages - should that navigation be re-written for every test case, or
just call some test that already does that?
I would extract that code into a helper class called Transporter and have the tests call it to easily navigate to the deep page in one method call.
I wrote about this and other test design patterns in a conference paper at the Pacific Northwest Software Quality Conference. Look for the Transporter pattern in that paper.
Here's an example using a Transporter class where you have to login and navigate to the checkout page:
public class Transporter {
public static void login() {
//App specific code to navigate to login screen and login to the application
}
public static void gotoCheckout() {
//App specific code to navigate to the checkout page
}
}
Now your tests can just call this Transporter class to do the navigation for them.
If you are using BDD, such as JBehave (not sure if Cucumber has the same feature) where you have the Given, When, Then story (feature) structure in Gherkin syntax, you can actually use "GivenStories" feature which are like prequel test cases to set you up for your specific test case, exactly as you are describing.
There's nothing wrong, however, when using BDD to simply make multiple step scenarios leading up to the particular test case, i.e. first scenario logs-in, second scenario navigates to certain page, third scenario performs your actual test.
By writing it as a separate story (feature), however, you can re-use those as "GivenStories" in JBehave as a shortcut to get where you need to be without duplicating the steps.
I pretty much only use JUnit Categories for non-unit tests that I don't want to run as part of the test suite. In NUnit I could use Explicit, but the only thing I've found comparable in JUnit is a Category. In gradle, it's simple to exclude a Category, but I can't figure out how to do this with IntelliJ's test runner. I see how to run tests that belong to a Category, but not how to exclude them.
Some time has passed since I asked this question, and in that time the Gradle test runner has become the default (at least for me). So though the built-in runner may not have this functionality, you can easily create a gradle task that excludes categories or tags:
test {
useJUnitPlatform {
excludeTags 'integrationTest'
excludeTags 'endToEndTest'
excludeTags 'testDriver'
}
options {
exclude '**/*Integration*'
exclude 'integrationTest'
exclude 'endToEndTest'
exclude 'testDriver'
}
}
I’d like to know if there is a way to really link the test of a build, with a test case WorkItem.
I've seen that you can attach the result of a test to a test case, but I want the test (method) to be linked to the test case, not the result.
I’m using Report Builder, where I show the list of test result of a build. The thing is, the name of each tests comes from the methods name. I’d prefer to use the name of the test case.
You cannot link a part of code (in this case a test method) to an work item (in this case a test case).
I was recently working with JUnit 3, but I decided to migrate to JUnit 4. Now Im facing the following problem:
I was using a TestSuite with JUnit 3, where I ran all java-Testclasses whose names matched a pattern like "*TestMe.java".
I've got a hundred tests which were named like this.
Now, with JUnit 4 I have to name them explicitly to call them in a TestSuite.
#RunWith(Suite.class)
#Suite.SuiteClasses(
{
FirstTestMe.class,
SecondTestMe.class,
ThirdTestMe.class,
})
public class TestMe
{
/**
* Constructor.
*/
private TestMe()
{
super();
}
}
This is really uncomfortable and I possibly might forget to list some tests. Also, when I create a new one, I must add it there.
Is there any solution how to call those Test-Classes with a Regex or something else?
Also, one additional question: each method which is not a test, but maybe used in a test-class must be annotated with #Ignore?
I run those test-classes without any error, so I guess it is not necessary?
You may want to have a look at the post migrate-tests-from-junit-3-to-junit-4 which discusses exactly what you want.
See if Dynamically create a Test Suite in JUnit 4 or Run all tests in Junit 4 helps.
Add the #Test annotation above your test method.
public class TestMe
{
#Before
public void setUp() {
}
#Test
public void myFirstTest() {
}
}
For your first question, if you want to use a Test Suite in JUnit 4, then there isn't any option but to list all of the classes explicitly. If, however, you want to run all classes in a package, or in a project, you can just right click on the package/project in Eclipse and select Run as JUnit test. If you're using ant or maven surefire, you can specify the tests to run with a *Test.java or similar.
You don't have to annotate those methods which are not test methods with #Ignore.
The (major) difference between JUnit 3 and JUnit 4 is the use of annotations. So it JUnit3, you extend TestCase and name all of your methods testXXX. In JUnit 4, you don't have to extend TestCase, but you do have to annotate all of your test methods with #Test. So therefore, any methods not marked with #Test don't get run as test. Of course, there are other annotations such as #Before and #After, which replace setUp() and tearDown().
There is an open source library ClasspathSuite. It allows you to use regular expressions to specify what class/package names should be or should not be included in your test suite.
Here's an example of use which includes everything in two packages but not in a third package. It also excludes another specific class.
#ClassnameFilters( { "com.javaranch.*test.*", "net.jforum.*test.*", "!com.javaranch.test.web.*", "!.*All_JForum_Functional_Tests" })
I found the comparison at http://www.mkyong.com/unittest/junit-4-vs-testng-comparison/. How to prepare something like #BeforeTest in JUnit?
As I understand it, BeforeTest specifies a method which is run before a set of tests is run, and defineable for that set of tests. There isn't an equivalent grouping in JUnit, except for normal Suites, so you have to define a suite and use #BeforeClass and #AfterClass in your suite as normal.
If you want more complex behaviour, see TestRule, in particular ExternalResource.
Not as familiar with TestNG, but from my understanding you can do something similar it with a combination of Categories, a Suite, and #BeforeClass/#AfterClass.
For example:
import org.junit.BeforeClass;
import org.junit.experimental.categories.Categories;
import org.junit.experimental.categories.Categories.IncludeCategory;
import org.junit.runner.RunWith;
import org.junit.runners.Suite.SuiteClasses;
#RunWith(Categories.class)
#SuiteClasses(MyClassTest.class)
#IncludeCategory(IntegrationTest.class)
public class StaticTests {
#BeforeClass
public static void setUp() {
System.out.println("Hello, World!");
}
}
Then within your tests flag things as #Category(IntegrationTest.class) and you'll have a logical grouping of tests–from multiple different test classes–which you can run initialization around.
Categories let you flag specific tests for inclusion in the suite, though it is also possible (if you separate out by class in the first place) just to include the relevant ones in the suite or have them inherit from a base class that has that configuration in it. Which one is best depends on how you like to group your tests and your specific use cases.
As Matthew Farwell mentions, there's also TestRules which give you a little finer-grained control for setting up around a set of tests.