Arquillian and Selenium in mixed Container/Client mode - java

i am reading the tutorial on Arquillian's website
http://arquillian.org/guides/functional_testing_using_drone/
Under the paragraph of "Enabling Client Mode" they state that it is possible to mix in-container and client modes in the same test! Just leave off the testable attribute. Any method annotated with #RunAsClient will execute from the client, the remainder will execute inside the container, giving you the best of both worlds!
Here is my Issue.
I want to write a test that users
#Drone
DefaultSelenium browser and
#EJB
MyXXXRepository
I have one test that will add a user to the InMemory database before i have a Selenium test which logs in on the browser with that user...
So in order to get Selenium to work i need to tell the #Deployment to be testable=false, this will cause my #EJB to fail.
So according to the documentation i can skip the testable=false, if i tell the Selenium Test Method that it should run in Client Mode. According to the documentation this should work.
But!!!
This will throw an Exception
Caused by: java.lang.NoClassDefFoundError: Lcom/thoughtworks/selenium/DefaultSelenium;
So i need to be able to tell the
#Drone
DefaultSelenium browser;
To be in Client Mode as well...
Any takers?

Drone is intended to be client side. Personally I've never tried to deploy WebDriver/Drone tests and run it from the server. This sounds a bit crazy :) And obviously since the test itself is mixed classloader complains about the Drone-related imports.
But I have a solution for you which lets you test from the "grey-box" perspective. There is a fairly new extension in Arquillian universe called Warp which allows you to solve your very problem. Here's the guide.
Hope that helps.

I solved the problem by using an import script that will import the user prior to the test, this way i do not need to instantiate the repository and it is now a clean client side test.

Related

Using LambdaClient.invoke in QuarkusTest how do I provide custom headers?

I'm trying to integrate Datadog into a Quarkus lambda function. The unit test is failing with a NullPointerException because Datadog can't get the function ARN from the context. It looks like there is a need to supply this header Lambda-Runtime-Invoked-Function-Arn in the HTTP request.
Is there anyway to customize the request headers using QuarkusTest? We are using LambdaClient.invoke.
Generally tests should be as close to the production run as possible, so altering headers does not seem to be the right path.
Is the unit test focused on the datadog part of the code?
If not:
If datadog just broke the existing unit tests, you have multiple options to fix it:
With #QuarkusTest you could just Mock the datadog related parts and register that instead of the original using #InjectMock.
I also found that using #QuarkusTest for unit testing can be a bit tricky in some cases and using plain Junit5 with Mockito can be a bit simpler with less unpredictable 'magic'.
If yes:
Since most things involving datadog is about sending data to an external service this might be more suitable for the scope of an integration test instead of a unit test. In that case you would need a test environment, or maybe reconsider if you really need to test external data collection at all.

Using Mockito for API Stubbing Load Test

I have a Spring Boot application with a REST API. Behind the scenes it uses a vended SDK to call the vendors service. I need to run load tests on my application, but don’t want to call the vendor API and accidentally crash their system during testing.
Is it possible to use Mockito outside of a JUnit test to create a mock for the vendor SDK objects during the normal application runtime?
I figured I would use a profile based configuration beam to enable the mocked object when profile is “performance-test”. But I can find no article/discussion/mention of anyone using Mockito this way and it is making me second guess my approach. Thoughts?
You probably should look for using wiremock or similar software to mock the vendor service, like here: Integration Testing with a fake server
Wiremock is a stub server that you can conveniently start/stop from within JUnit tests. It acts like the remote server when you set up responses. The documentation is really good, I do not want to copy&paste all of it here.
Just a sample:
public class MyTest {
#Rule
public WireMockRule wireMockRule = new WireMockRule(wireMockConfig().dynamicPort().dynamicHttpsPort());
#Test
public void exampleTest() {
stubFor(get(urlEqualTo("/my/resource"))
.willReturn(aResponse()
.withStatus(200)
.withBody("<response>Some content</response>")));
...
verify(postRequestedFor(urlMatching("/my/resource/[a-z0-9]+"))
.withRequestBody(matching(".*<message>1234</message>.*")));
}
}
For loadtest, you would rather run the stub standalone somewhere, and have some script set up the responses.
You probably don't find mention of Mockito because embedding mocks with stub responses into your application is a bad idea and will not help you getting realistic results for load tests (because your responses will be much faster and not pass through serialization/deserialization).
Else also look here:
How to mock remote REST API in unit test with Spring?

Running tests involves background theads performing db operations hungs when running inside a Junit Suite

Background
We are building a product using Spring / Hibernate (JPA based) / Restful API from Jersey. During project build phase , we are running Integration tests to make sure that all the Restful API's are behaving as expected.
In recent past, we have migrated to use two entity managers which is used for another sub-product merged with this. Things become started messing up from there onwards
We are having background threads which performs few operations asynchronously. Initially we faced issues for these background jobs to get hold of their respective Entity manager factory. But we somewhat solved the issue using OpenEntityManagerInViewFilter.
As part of integration tests run , we will be bringing up Jetty server and deploy the application there for testing.
Current problem Scenario
When running those tests involves the background processing individually, they are running fine.
As we had multiple tests in place , Starting and stopping Jetty server resulted in long duration of tests run.
So we have grouped all tests inside a test suite and configured this suite inside the surefire-plugin.
The tests which have worked individually started hanging under running inside a suite.
Test Suite setup is given below.
#BeforeClass
public static void setUp()
{
// Startup of jetty server happens here
}
#AfterClass
public static void tearDown()
{
// Stopping of jetty server happens here
}
In individual tests, we will complete the background process in #BeforeClass and performing the data cleanup activities in #Afterclass method.
I am litte weird about how the tests works fine as individual starts causing issues when running inside a test suite
Any configuration / ideas would be much appreciated.
My guess is that it is one of these things:
You are not mocking something correctly, and you are changing the state of the data you are using in tests
You are doing some operations on your database that the test is not able to "repair" (e.g. drop or rename table)
You are using some static variables somewhere and these are building you a state machine that you don't expect/want
If you can say how the tests are failing, that might help
The problem seems to happen due to connections are not returned from connection pool after being used. Once we started increasing the maximum.connection.pool.size the issue stops occurring.
Thanks for all your comments

Passing server parameters as arquillian resource?

I'm using arquillian for functional tests only. Arquillian is not managing a container (standalone) and is not deploying an app (also done manually. Since there's no deployment I can't obtain deploymentUrl using #ArquillianResource.
Also, it's a maven project and I have a property with server hostname which is pretty much what I need to get in arquillian test.
My question is: what would be another option to acquire a url except for hard coding it?
If the tests are run in client JVM, you can probably use system properties. For example, with maven it could be:
$ mvn test -Ddeployment.url=http://whatever
And in test code:
String url = System.getProperty("deployment.url", "http://defaulturl");

Junit test case: Connection refused case

I am writing a Junit(4.x) test to test what happens when the web application is down.
When I hit the url in the browser, I get a message saying "Connection refused".
I am unsure about what to check for in the assert statements.
Do I check the header for this message? -- urlConnection.getResponseMessage() or
just say (expected = java.net.ConnectException) before the test case. I feel the latter is not specific enough.
EDIT: Right now, I'm using a combination of (expected = java.net.ConnectException) and assertEquals(502, urlConnection.getResponseCode). The test is passing.
Thanks,
Pratyusha.
First of all, your unit tests should not depend so much on external entities. What you describe is rather an integration test.
In a classic unit test, you could set up this scenario by using e.g. a mock HttpUrlConnection. This can be programmed to throw an exception from the desired method call. If you are not happy by simply acknowledging the type of exception thrown, you can always catch it within the test method, then assert the response message or whatever you are interested in.
However, from your post it is not clear to me what are you actually testing: a web client which depends on a server? A web app which calls another web app? Different tests may be adequate for different scenarios.
Integration tests in junit are fine. Many widely used open source projects use this approach. See CXF or Arquillian for examples of this approach.
For your question... you need to decide what the desired behaviour is and then test for this.
For example in this case you probably want to test the response code the server is returning. Or if "connection refused" really is desired behaviour then testing for (expected = java.net.ConnectException) should be sufficient.

Categories