This question already has answers here:
Running JUnit Tests in Parallel in IntelliJ IDEA
(3 answers)
Closed 5 years ago.
Is it possible to run junit tests in intelliJ in parallel? If so, how do i do this?
I set the "fork" parameter to class level and this didn't do anything - actually, it made everything a bit slower, so i'm unsure what "fork" does that is beneficial?
Is it possible to do this just using intelliJ, or do i need some fancy test framework and all the hoo-hah that that would involve?
Finally, assuming this is at all possible, can one control the number of forks or threads or whatever they want to call it?
UPDATE: somebody has linked to a question that might answer this. I looked at that question prior to posting - I'm unsure what that question really "answers". It simply says there is an issue tracker and that this issue has been implemented in intelliJ. I don't see how to implement it anywhere.
UPDATE: What does "didn't do anything" mean?: it just makes things slower, which isn't v. useful. I mean, maybe your tests run blazingly quickly and you want to slow them down to appreciate some Bach? That is cool. I just want mine to run faster, I'm fed up of Bach.
You can make use of the junit-toolbox. This is an extension library for jUnit that is listed on the jUnit site itself.
This extension offers the ParallelSuite. Through this you can create with nearly no effort an AllTest class that executes the tests in parallel. The minimum AllTest could look like the code below, using the pattern feature introduced with junit-toolbox.
#RunWith(ParallelSuite.class)
#SuiteClasses("**/*Test.class")
public class AllTests {}
This will create as many threads for parallel execution as your JVM reports via availableProcessors. To override this you may set the system property maxParallelTestThreads.
Related
This question already has an answer here:
How can we execute WebUI feature file against multiple browsers using parallel runner or distributed testing?
(1 answer)
Closed 1 year ago.
We have a requirement to run the entire test suite more than once considering different parameters.
Say, I have 5 feature files and each has 10 scenarios. I have a requirement to run these feature files twice one after the other.
There is a way to achieve this using Scenario Outline, which will execute each scenario for the number of parameters. But can we have all the scenarios run once for the 1st parameter and then all the scenario again for the 2nd parameter. Something like an Outline at Feature level.
Please suggest.
I think this should be done at the JUnit / Java runner level. Teams usually use tags to enable or disable features at run time.
Or you can create a "wrapper" feature that calls a second feature etc.
Otherwise please assume that what you want is not directly supported, you are welcome to contribute code to Karate if needed. My honest opinion is that this is not required in a testing framework, maybe you should just write code.
EDIT - see this answer, I think you will be able to figure out an approach based on it: https://stackoverflow.com/a/60387907/143475 - and keep in mind Karate supports a "dynamic" Scenario Outline.
Can someone tell me please: how to take a screenshot when test method fails (jUnit 5). I have a base test class with BeforeEach and AfterEach methods. Any other classes with #Test methods extends base class.
Well, it is possible to write java code that takes screenshots, see here for example.
But I am very much wondering about the real problem you are trying to solve this way. I am not sure if you figured that yet, but the main intention of JUnit is to provide you a framework that runs your tests in various environments.
Of course it is nice that you can run JUnit within your IDE, and maybe you would find it helpful to get a screenshot. But: "normally" unit tests also run during nightly builds and such - in environments where "taking a screenshot" might not make any sense!
Beyond that: screenshorts are an extremely ineffective way of collecting information! When you have a fail, you should be locking for textual log files, html/xml reports, whatever. You want that failing tests generate information that can be easily digested.
So, the real answer here is: step back from what you are doing right now, and re-consider non-screenshot solutions to the problem you actually want to solve!
You don't need to take screen shots for JUnit test failes/passes, rather the recommended way is to generate various reports (Tests Passed/Failed Report, Code coverage Report, Code complexity Report etc..) automatically using the below tools/plugins.
You can use Cobertura maven plugin or Sonarqube code quality tool so that these will automatically generate the reports for you.
You can look here for Cobertura-maven-plugin and here for Sonarqube for more details.
You need to integrate these tools with your CI (Continuous Integration) environments and ensure that if the code is NOT passing certain quality (in terms of tests coverage, code complexity, etc..) then the project build (war/ear) should fail automatically.
i have a question about JUnitServlet in CQ5 integration testing. I dont understand 2 things and i need help from somebody that had similar problem. So far I have package with only one test class with several testing methods. Everything works fine but there are this 2 problems:
Why when I change the name of the testing class, the JunitServlet doesn't find it anymore. Even though i am doing building again and exporting the package and everything but just doesn't find it. It doesn't want to accept any other name different than the first one that i gave to the testing class. I want to change it because in the beginning i gave very specific name and than i added several testing methods and I want to change it to more general one for example "TestScenarioOne.java" ...
The second problem is that after I finished this testing class I created new one to continue to test different scenarios. JUnitServlet finds just the first one but not and the new one as well ... Even though they are in the same package. I don't know what is the problem...
Thanks a lot and I am waiting for your answers ...
I find out what is the problem :) In Older versions of Junit there is a naming convention of the testing class to contain the noun "Test" at the end. I was told that it in Junit version 4+ this was removed... Even though we use Junit 4+ version I tried and it works that was the only problem ... I hope this question will be also useful to other novices in cq5 integration testing with JUnitServlet ... Thanks :)
I put the answer as a comment few days ago but I decided to answer my question with an official answer so that it appears as answered question when somebody searches for something similar. Thanks
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I often feel that after iterating over my code for a number of times I am left with functions or classes or other lines of code in general which made sense in the previous revision but are not very useful for the new revision. I know that a profiler can tell you what part of your code was called when you run your test cases? But how does one go about identifying what part of the code never got called to remove it so that whats left is more readable? For example, is there a quick way to know which functions in your code are not being called from anywhere and can be safely removed. It may sound like a trivial question for a small code base, but when your code base grows over the years, this becomes an important and not so trivial question.
To summarize the question, for different languages, what is the best approach to remove dead code? Are there any lanaguage agnostic solutions or strategies for this. Or does each language provide a tool for identifying dead code.
We normally program in Java or Python or Objective-C.
The term you're looking for is "code coverage" and there are various tools that will generate that information. You would have to make sure that you exercise every possible path through your code in order to be able to detect "dead code" with such a tool though, which is only possible with a really extensive set of tests.
Most compilers have some level of dead code detection, but that only detects code that cannot possibly be called, not code that will never be called due to program logic, etc..
edit:
for Python specifically: How can you find unused functions in Python code?
for Java: How to find unused/dead code in java projects, Java: Dead code elimination
for Objective-C: Xcode -- finding dead methods in a project, Cleaning up Objective-C code
For functions, try a global search on the function name, and analyze what you get. Dead code inside a function will usually be findable.
If you suspect a function of being unused, you can remove it, or comment it out, and see if what you've got still compiles.
This only works on functions that are unused because they are no longer called. Functionality that is never used because the control path through the code is no longer active is harder to find, and code analysis tools won't do well at finding it either.
You can use the code coverage report to find out the function which are not used or part of function which is never executed.
Based on the logic, you can treat them as dead code/unused code.
Popular code coverage tools that can be used:
C/C++: gcov & lcov
Python: Coverage.py
Java: JCov
Objective-C: xccov
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I'm familiar with jUnit, and heard TestNG might be a solution to some of jUnit's annoyences - e.g. its insistence to create a separate instance of the test class per test, thus forcing me to use static field for objects I want to reuse between tests.
(Let's say you agree with me that this is a drawback, and not turn this question to something it's not)
What I'm asking here, is what drawbacks does TestNG have, compared to jUnit? Why not use TestNG, assuming this is a new project and there isn't any migration cost?
I'm the creator of TestNG. I'm not going to weigh in since I'm obviously biased, but I'm happy to answer any question you might have about TestNG.
Andy: thanks for your comment. FYI (you probably already know that but maybe the original poster doesn't), there is a TestNG Eclipse plug-in (which I develop in parallel to TestNG).
I personally have not encountered any significant drawbacks compared to JUnit.
At the start of a new project, my team switched to TestNG and had no regrets. TestNG is more powerful and supports broader usage than unit tests.
Some tools support JUnit but not TestNG. These are tools that I have not yet needed. For example:
Google's CodePro Analytix supports generation of JUnit unit tests.
The Eclipse IDE for RCP development supports run/debug configurations for "JUnit plug-in tests."
Being a huge supporter of TestNG I still see it is treated as being number 2 by tools authors. Many tools and libraries support JUnit from the very beginning, but you have to wait till they also implement support for TestNG. This might be a serious drawback if you plan to use some latest buzzing technology.
Over the years situation improved a lot. For example this used to be an issue with Spring, Gradle, or Maven Surefire but is no longer a problem because they all support TestNG now. Also all IDEs are treating both frameworks equally.
So, make sure the other technologies you plan to use play nicely with TestNG. This is rarely a problem, but still better make sure of it ahead.
For me the biggest problem is an integration with spring.
I do not like to extend TestNg classes and write code like this:
#Test
#ContextConfiguration(locations = { "classpath:spring-test-config.xml" })
public class TestSpring extends AbstractTestNGSpringContextTests {
Because usually I have my own hierarchy of test classes.
This was the main reason why I stopped using TestNg.
I must agree that parameterized test was very attractive for me. But they can be easily replaced with junit data-provider.
https://github.com/TNG/junit-dataprovider/wiki/Getting-started