How to use Interface IReporterConfig class of org.testng.reporters package

Most testing frameworks (the xUnit family) are based on the JUnit framework. The Assert family of functions in JUnit have the (expected, actual) format; it became a convention, and most of the other frameworks followed that convention.

Some frameworks (like TestNG or NUnit 2.4+ for .NET) reversed that order (with the use of a constraint-based model for NUnit) to increase readability ("make sure that the actual value is 56" feels more natural than "make sure that 56 is the actual value").

The bottom line is: stick to the convention of your framework. If you use JUnit, put the expected value first. If you use TestNG, put the actual value first. You're right, that makes no difference in the test results when you accidentally reverse the arguments. But it makes a big difference in the default message you get from a failing test. When your reversed assertEquals(ShouldBeTrueButReturnsFalse(), true) in JUnit fails, the default message says "expected [false] but found [true]", where it should have said "expected [true] but found [false]". This is confusing, to say the least, and you shouldn't have to deal with a possible misdirection of that message.

Some of the unit tests in the Github link you provide don't follow the convention and have the same problem. Don't do that. Stick to the convention of your framework.

@WithMockUser creates the authentication in SecurityContext. Same applies for with(user("username")).

By default the OAuth2AuthenticationProcessingFilter does not use the SecurityContext, but always build the authentication from the token ("stateless").

You can easily change this behavior be setting the stateless flag in the resource server security configuration to false:

@Configuration
@EnableResourceServer
public class ResourceServerConfiguration implements ResourceServerConfigurer {

    @Override
    public void configure(ResourceServerSecurityConfigurer security) throws Exception {
        security.stateless(false);
    }

    @Override
    public void configure(HttpSecurity http) {}

}

Another option is to extend ResourceServerConfigurerAdapter, but the problem with that is that it comes with configuration that forces all requests to be authenticated. Implementing the interface leaves your main security config unchanged apart from the statelessness.

Of course, set the flag to to false in your test contexts, only.

The error says it all :

[RemoteTestNG] detected TestNG version 6.14.2 Starting ChromeDriver (v2.9.248307) on port 34979 
[warn] kq_init: detected broken kqueue; not using.: Undefined error: 0 Mar 12, 2018 7:06:13 AM 
org.openqa.selenium.remote.ProtocolHandshake createSession 
INFO: Detected dialect: OSS FAILED: test1
org.openqa.selenium.WebDriverException: java.net.ConnectException: Failed to connect to localhost/0:0:0:0:0:0:0:1:34979 
Build info: version: '3.10.0', revision: '176b4a9', time: '2018-03-02T19:03:16.397Z' 
System info: host: 'sandeep-MacBook-Pro.local', ip: '192.168.0.100', os.name: 'Mac OS X', os.arch: 'x86_64', os.version: '10.13.3', java.version: '1.8.0_101'

Your main issue is the version compatibility between the binaries you are using as follows :

• You are using chromedriver=v2.9
• Release Notes of chromedriver=2.9 clearly mentions the following :

Supports Chrome v31-34

• Your Chrome Browser version is unknown to us. (assuming Chrome Browser is updated to v65.x level)
• Your Selenium Client version is 3.10.0.
• Your JDK version is 1.8.0_101 which is pretty ancient.

So there is a clear mismatch between the JDK v8u101 , Selenium Client v3.10.0 , ChromeDriver version (v2.9) and the current Chrome Browser version (v65.0)

Solution

• Upgrade JDK to recent levels JDK 8u162.
• Keep Selenium to current levels Version 3.10.0.
• Upgrade ChromeDriver to stable ChromeDriver v2.36 level.
• Keep Chrome version at Chrome v65.x levels. (as per ChromeDriver v2.36 release notes)
• Clean your Project Workspace through your IDE and Rebuild your project with required dependencies only.
• Use CCleaner tool to wipe off all the OS chores before and after the execution of your test Suite.
• If your base Chrome version is too old, then uninstall it through Revo Uninstaller and install a recent GA and released version of Chrome.
• Execute your @Test.

From the Mockito documentation :

Resetting mocks (Since 1.8.0)

Smart Mockito users hardly use this feature because they know it could be a sign of poor tests. Normally, you don't need to reset your mocks, just create new mocks for each test method. Instead of reset() please consider writing simple, small and focused test methods over lengthy, over-specified tests. First potential code smell is reset() in the middle of the test method. This probably means you're testing too much. Follow the whisper of your test methods: "Please keep us small & focused on single behavior". There are several threads about it on mockito mailing list.

The only reason we added reset() method is to make it possible to work with container-injected mocks.

You should probably just recreate the spy in a @BeforeMethod :

public class Program {

    private TestObject testObject = new TestObject();
    private TestObject spyTestObject;

    @BeforeMethod
    public void buildSpy() {
        spyTestObject = spy(testObject);
    }

    @Test
    public void test1() {
       spyTestObject.makeSth(); 
       verify(spyTestObject , only()).someMethodNeedToBeChecked(); 
    }

    @Test
    public void test2() {
        // Some different scenario
       spyTestObject.makeSth(); 
       verify(spyTestObject , only()).someMethodNeedToBeChecked(); 
        ...
    }
}

You archive the screenshot using the "archive the artifacts" option in the "post build actions" of the jenkins project configuration page.To archive first u need to set the custom workspace for the project.The custom workspace should point to the root directory or the folder which is containing the folder of screenshots.Then after archiving all the screenshots will appear as links in the project page.Here "reports" will be folders containing the screenshots or any file.reports is under The "QTP" folder which is mentioned in the custom workspace.pls use slash instead of backslash in the archive the artifacts option.

Project page:

using custom workspace in jenkins

archiving the artifacts using post build actions

You may want to try mockito. The test works like this:

You use mockito to "implement" EntityManager. Instead of the real code, you use the methods of mockito to say "if the application calls getReference(), then return this object". In the background, mockito will create a proxy instance which intercepts the Java method calls and returns the values which you specify. Calls to other methods will return null.

Mocking things like createQuery() works the same way but you first need to create a mockup of Query and then use the same approach as in getReference() (return the query mockup).

Since you don't use a real EM, you don't need a real persistence.xml.

A much more simple solution would be if you could set some property to change the name of the persistence.xml file but I don't think that this is possible.

Some other links that may help:

• How to configure JPA for testing in Maven
• Suggest a JPA Unit test framework

You can use java code record your Test video, for this code to run you also need to add jar file to your project : Reference : Road to automation

@BeforeSuite
        public void startRecording() throws Exception {    

           GraphicsConfiguration gc = GraphicsEnvironment
                   .getLocalGraphicsEnvironment()
                   .getDefaultScreenDevice()
                   .getDefaultConfiguration();

               this.screenRecorder = new ScreenRecorder(gc,
                   new Format(MediaTypeKey, MediaType.FILE, MimeTypeKey, MIME_AVI),
                   new Format(MediaTypeKey, MediaType.VIDEO, EncodingKey, ENCODING_AVI_TECHSMITH_SCREEN_CAPTURE,
                        CompressorNameKey, ENCODING_AVI_TECHSMITH_SCREEN_CAPTURE,
                        DepthKey, 24, FrameRateKey, Rational.valueOf(15),
                        QualityKey, 1.0f,
                        KeyFrameIntervalKey, 15 * 60),
                   new Format(MediaTypeKey, MediaType.VIDEO, EncodingKey, "black",
                        FrameRateKey, Rational.valueOf(30)),
                   null);
       this.screenRecorder.start();

    }

    @AfterSuite
    public void stopRecording() throws Exception {
      this.screenRecorder.stop();
    }

I think

Mockito.reset(wareHouseSpy)

would do it.

There is no method on FileReader/FileWriter to tell you what file it points to (because theoretically you should never need to know - that's why you're working with the reader and not the File).

You could use reflection to read private fields of the underlying FileInputStream/FileOutputStream.

But I think the correct approach to this is don't test things that cannot break - namely, don't test the Java core libraries. Unless the code posted is a simplified version, testInitiateFileWriter() is effectively testing new FileWriter (getFile(path),false), and you already know that getFile(path) works (as per your passing test), so the only thing you're testing here is new FileWriter(...).

Footnote: Of course Java libraries can break / contain bugs, but the chance is negligible in most cases and for such widely-used part as FileReader/FileWriter.