How to use IgnoredMethodsPanel class of org.testng.reporters.jq package

From Javadoc:

Some virtual machines may, under some circumstances, omit one or more stack frames from the stack trace. In the extreme case, a virtual machine that has no stack trace information concerning this throwable is permitted to return a zero-length array from this method.

So, the only guaranteed way to do this is to use aspects, or collect stack trace with some other custom way. But you can combine this approach with fallback to some way of getting current method's name (for case when your logTitle method will be inlined). It can be found here, for example. Again, no guarantee, but better chance.

You need to run this with PowerMockRunner

eg.

@RunWith(PowerMockRunner.class)
@PrepareForTest({ ExampleEnumerable.class})
@Test(groups = {"LoadableBuilderTestGroup"})
public class LoadableBuilderTest {
    private ExampleEnumerable mockEnumerable;

    @BeforeMethod
    public void setUp() {
        mockEnumerable = mock(ExampleEnumerable.class);
    }
}

when(listaFilmes.get(anyInt())).thenReturn(any(Filme.class));

There's your problem. You can't use any in a return value. any is a Matcher—it's used to match parameter values for stubbing and verification—and doesn't make sense in defining a return value for a call. You'll need to explicitly return a Filme instance, or leave it null (which is the default behavior, which would defeat the point of stubbing).

I should note that it's often a good idea to use a real List instead of a mock List. Unlike custom code you've developed, List implementations are well-defined and well-tested, and unlike mock Lists a real List is very unlikely to break if you refactor your system under test to call different methods. It's a matter of style and testing philosophy, but you may find it advantageous just to use a real List here.

Why would the above rule cause that exception? Well, this explanation breaks some of Mockito's abstractions, but matchers don't behave like you think they might—they record a value onto a secret ThreadLocal stack of ArgumentMatcher objects and return null or some other dummy value, and in the call to when or verify Mockito sees a non-empty stack and knows to use those Matchers in preference to actual argument values. As far as Mockito and the Java evaluation order are concerned, your code looks like the following:

when(listaFilmes.get(anyInt())).thenReturn(null);
when(filmeDao.listAll(any())).thenReturn(listaFilmes); // nonsense

Naturally Mockito sees an any matcher, and listAll doesn't take an argument, so there are 0 matchers expected, 1 recorded.

By default IntelliJ Idea uses Gradle to build and run tests (for Gradle projects). You can change this in Settings -> Build, Execution, Deployment -> Build Tools -> Gradle -> Run tests using

You can either change it to IntelliJ IDEA to always choose the TestNG Runner or set it to choose per test. This will create a run (test) config where IDEA remembers which option you chose. In order to choose again, simply delete the run config for the respective test.

First, you can't prevent people from messing with your game by declaring things 'final'. There are reflection tricks and whole code generation libraries that make it merely slightly inconvenient to get past this.

So, lose the finals, and then you can use jmock or whatever library you like to make mocks.

You haven't changed the default surefire execution which is bound to the test phase in the superpom, so it's still running with its default config. The id of that execution is "default-test". You'll either need to override it to unbind it from the test phase or else just use that id for one of your own executions.

There are lots of problems here.

First, I count three citations of the JNDI lookup string in your small example. DRY would tell you to write it once and refer to it, if possible.

Second, I don't appreciate your DAO very much. Is this really what you're writing, or is this just an example? I don't think this is the Spring idiom. There's no interface. How will you do declarative transactions without one? I'd recommend looking at the Spring docs for iBatis more carefully.

Third, I'd recommend using JUnit 4.4 or, better yet, the TestNG idiom - annotations. Also check out the Spring @ContextConfiguration to inject the beans you need in setUp.

Fourth, your DAOs cannot work because you need a JNDI lookup service running, and you can't get one without the container. The answer is to have a DriverManager data source for your tests.

UPDATE: Here's an idea to try: Use the Spring idiom for iBatis. If legacy prevents you from doing this, perhaps Spring isn't your answer.

Once you do this, all you have to do is override the data source app context to use DriverManager instead of JNDI for your test.

You can use the dependsOnMethods or dependsOnGroups annotation parameter in your other test methods:

@Test(dependsOnMethods = {"stopTestingIfThisFailed"})
public void testAnotherTestMehtod()  {

}

JavaDoc of the dependsOnMethods parameter:

The list of methods this method depends on. There is no guarantee on the order on which the methods depended upon will be run, but you are guaranteed that all these methods will be run before the test method that contains this annotation is run. Furthermore, if any of these methods was not a SUCCESS, this test method will not be run and will be flagged as a SKIP. If some of these methods have been overloaded, all the overloaded versions will be run.

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

I may not be able to talk about any standard pattern, but here are a few things that I consider:

1. Make good use of Test Execution frameworks. I use TestNG.
2. I create a base file which makes use of most of the TestNG annotations for Setting and Tearing up.
3. Separate your Re-usable functions and call it wherever needed. I generally add these in the base class.
4. I personally prefer keeping locators too in the base file if they are too complicated. This would help you to change the locator from one place and get reflected for all. In this case, do follow a good naming convention.
5. Use collections wherever possible.
6. You can use something like ReportNG for more user friendly reports.
7. Make more use of implicit waits and avoid using JavascriptExecutors.
8. Copy the Drivers and libraries within the project folders for better mobility and less external dependencies.
9. Adding selenium WD javadoc to your project will be of some help.
10. We also make sure we have a screenshot for failed test case by over-riding the onTestFailure method.
11. Rest all are simple coding basics for cleaner and easy to understand code that I believe you'll be following anyway.

Hope this was of some help. Will add more points if I'm able to recall. Also, please let me know if you need more details for any of these things.