How to use onTestSkipped method of org.testng.reporters.VerboseReporter class

It is a very stupid mistake that maybe someone new to testNG may make...

@BeforeGroups("regression") 

This is a wrong usage.. The correct usage should be:

@BeforeGroups(groups = "regression")

Took me two days!!

If you have a google drive or dropbox accounts, you probably have "dropbox" or "doogle drive" applications installed. Those applications sync contents of your local folders with the cloud. Simply save your screenshots in that folder and you're good to go. Google Drive app Dropbox app

If you experience problem with saving the screenshot itself, please provide the error message you get, or at least a screenshot. I'll be glad to help.

The easy way is to just change @Test to @Test(singleThreaded=true). If you do, all of the tests in your class will run sequentially in a single thread.

Or

If you want to be explicit about the order that the tests should run in, you can use the annotation @dependsOnMethods

public void orange(){}

@Test(dependsOnMethods = { "orange" })
public void apple(){}

@Test(dependsOnMethods = { "apple" })
public void mango(){}

This is also nice if you want some, but not all, of the methods in a class to run sequentially.

http://testng.org/doc/documentation-main.html#dependent-methods

When I had this problem in my Selenium project I realized that I was using junit and TestNG as well. I removed TestNG codes and dependency from pom.xml. This way I only had junit in my project left. Then everything worked like charm, MVN test results showed the correct numbers.

Have your test classes implement org.testng.ITest and override getName() to return what you want. I believe IDEA honors this (not 100% sure, try it).

Add priority to the method you want to run last..do not add priorities to any other methods. The one with priority added would run last.

Yes, that's the default behavior of TestNG and I had introduced it through that pull request to fix the bug https://github.com/cbeust/testng/issues/2022

To set the JVM arguments in intelliJ, choose Run > Edit Configurations, and add this JVM argument in the VM options section after -ea (which would be there by default.

For more information on editing configurations, please refer to the official documentation here

Added screenshot for easy to find in Intellij

Argument value

-ea -Dtestng.dtd.http=true

If the above does not work do at template level, this will fix it, which is

Run--> Edit configuration --> template --> testng

1. They are tools to help you organize your tests. You can define what you want to run before/after tests, you can group your tests, and reporting on them is made easier.

2. It is usually mentioned with Selenium because Selenium is a common testing tool. The two work together well, but they are completely separate. (Selenium connects you to your browser, TestNG/JUnit organizes the tests)

3. Yes. You should be able to pick them up. They are designed to be fairly easy to learn.

1. Redirection is a simpler way to handle different pages depending on role. The filter could be used simply for authentication, to get the User object and any associated Roles into the session.

   As James Black said, if you had a central controller you could obviate the need to put this logic in the filters. To do this you'd map the central controller to all urls (or all non-static urls). Then the filter passes a User and Roles to the central controller which decides where to send the user. If the user tries to access a URL he doesn't have permission for, this controller can decide what to do about it.

   Most major MVC web frameworks follow this pattern, so just check them out for a better understanding of this.

2. I agree with James here, too - you don't have to move everything there but it can make things simpler in the future. Personally, I think you often have to trade this one off in order to work efficiently with designers. I've often put the infrastructure and logic in to make it work but then littered my templates with static text while working with designers. Finally, went back and pulled all the static text out into the external files. Sure enough, found some spelling mistakes that way!

3. Testing - this is the big one. In my experience, a highly disciplined test-first approach can eliminate 90% of the stress in developing these apps. But unit tests are not quite enough.

   I use three kinds of tests, as indicated by the Agile community:

   • acceptance/functional tests - customer defines these with each requirement and we don't ship til they all pass (look at FitNesse, Selenium, Mercury)
   • integration tests - ensure that the logic is correct and that issues don't come up across tiers or with realistic data (look at Cactus, DBUnit, Canoo WebTest)
   • unit tests - both defines the usage and expectations of a class and provides assurance that breaking changes will be caught quickly (look at JUnit, TestNG)

So you see that unit testing is really for the benefit of the developers... if there are five of us working on the project, not writing unit tests leads one of two things:

• an explosion of necessary communication as developers try and figure out how to use (or how somebody broke) each other's classes
• no communication and increased risk due to "silos" - areas where only one developer touches the code and in which the company is entirely reliant on that developer

Even if it's just me, it's too easy to forget why I put that little piece of special case logic in the class six months ago. Then I break my own code and have to figure out how... it's a big waste of time and does nothing to reduce my stress level! Also, if you force yourself to think through (and type) the test for each significant function in your class, and figure out how to isolate any external resources so you can pass in a mock version, your design improves immeasurably. So I tend to work test-first regardless.

Arguably the most useful, but least often done, is automated acceptance testing. This is what ensures that the developers have understood what the customer was asking for. Sometimes this is left to QA, and I think that's fine, but the ideal situation is one in which these are an integral part of the development process.

The way this works is: for each requirement the test plan is turned into a script which is added to the test suite. Then you watch it fail. Then you write code to make it pass. Thus, if a coder is working on changes and is ready to check in, they have to do a clean build and run all the acceptance tests. If any fail, fix before you can check in.

"Continuous integration" is simply the process of automating this step - when anyone checks code in, a separate server checks out the code and runs all the tests. If any are broken it spams the last developer to check in until they are fixed.

I once consulted with a team that had a single tester. This guy was working through the test plans manually, all day long. When a change took place, however minor, he would have to start over. I built them a spreadsheet indicating that there were over 16 million possible paths through just a single screen, and they ponied up the $10k for Mercury Test Director in a hurry! Now he makes spreadsheets and automates the test plans that use them, so they have pretty thorough regression testing without ever-increasing QA time demands.

Once you've begun automating tests at every layer of your app (especially if you work test-first) a remarkable thing happens. Worry disappears!

So, no, it's not necessary. But if you find yourself worrying about technical debt, about the big deployment this weekend, or about whether you're going to break things while trying to quickly change to meet the suddenly-urgent customer requirements, you may want to more deeply investigate test-first development.