We are developing 2 different web applications (WARS).
Both use the same message bus (ActiveMQ - jms).
We would like to preform tests that triggers one action on a webapp#1 , that action should induce message throwing that will be consumed on webapp#2 and mutate the DB.
How can we test this end to end scenario??
We would like to have an automated test for that, and would like to avoid manual testing as much as possible.
We are using junit with springframework, and already have tons of junit that are being preformed daily, but non of them so far involved the usage of the message bus. it appear that this scenarion is a whole different story to automate.
Are there any possibilities to test this scenario with automated script (spring \ junit \ other)?
A JUnit test could certainly this integration test sequence:
send a HTTP request to webapp#1 to trigger, using HTTPUrlConnection for example
run a SQL command (using JDBC) to detect wether the database contains the expected value
In the test setup, the database needs to be initialized (rest) so that the second step does not give a false-positive result
Related
I have 2 queries and a db connection that i would like to make once as part of testing
CSRF
DB CONNECT
LOGIN
And then comes the API method I need that I'm testing. Here it needs to be run a number of times.
I read the documentation, but I still don't understand. Please help.
Put them under the Once Only Controller, its children are being executed only during the 1st iteration of the Thread Group
I also see a number of Listeners in your Test Plan, when you finish test development and debugging don't forget to remove them as they don't add any value and only consume resources, you should execute your JMeter test plan in command-line non-GUI mode with all listeners disabled or deleted and once it's finished you can use Listeners to analyze the .jtl results file (or just generate HTML Reporting Dashboard from it)
I have created an integration test to test the USERNAME_CONFLICT of my app as it's not allowed to have the same username twice.
What I did is that I called the same request twice in the same test (using TestRestTemplate) so that the second call will return USERNAME_CONFLCT and that's what I want in order for my test to succeed.
My problem is that the test is taking too much time, over 800ms and I don't think this is a good practice. What Ideas do you have to test such cases while the test time remains minimal?
I have a number of feature files in my cucumber scenario test suite.
I run the tests by launching Cucumber using the CLI.
These are the steps which occur when the test process is running:
We create a static instance of a class which manages the lifecycle of testcontainers for my cucumber tests.
This currently involves three containers: (i) Postgres DB (with our schema applied), (ii) Axon Server (event store), (iii) a separate application container.
We use spring's new #DynamicPropertySource to set the values of our data source, event store, etc. so that the cucumber process can connect to the containers.
#Before each scenario we perform some clean up on the testcontainers.
This is so that each scenario has a clean slate.
It involves truncating data in tables (postgres container), resetting all events in our event store (Axon Server container), and some other work for our application (resetting relevant tracking event processors), etc.
Although the tests pass fine, the problem is by default it takes far too long for the test suite to run. So I am looking for a way to increase parallelism to speed it up.
Adding the arguments --threads <n> will not work because the static containers will be in contention (and I have tried this and as expected it fails).
The way I see it there is are different options for parallelism which would work:
Each scenario launches its own spring application context (essentially forking a JVM), gets its own containers deployed and runs tests that way.
Each feature file launches its own spring application context (essetially forking a JVM), gets its own containers deployed and runs each scenario serially (as it would normally).
I think in an ideal world we would go for 1 (see *). But this would require a machine with a lot of memory and CPUs (which I do not have access to). And so option 2 would probably make the most sense for me.
My questions are:
is it possible to configure cucumber to fork JVMs which run assigned feature files (which matches option 2 above?)
what is the best way to parallelise this situation (with testcontainers)?
* Having each scenario deployed and tested independently agrees with the cucumber docs which state: "Each scenario should be independent; you should be able to run them in any order or in parallel without one scenario interfering with another. Each scenario should test exactly one thing so that when it fails, it fails for a clear reason. This means you wouldn’t reuse one scenario inside another scenario."
This isn't really a question for stack overflow. There isn't a single correct answer - mostly it depends. You may want to try https://softwareengineering.stackexchange.com/ in the future.
No. This is not possible. Cucumber does not support forking the JVM. Surefire however does support forking and you may be able to utilize this by creating a runner for each feature file.
However I would reconsider the testing strategy and possibly the application design too.
To execute tests in parallel your system has to support parallel invocations. So I would not consider resetting your database and event store for each test a good practice.
Instead consider writing your tests in such a way that each test uses its own isolated set of resources. So for example if you are testing users, you create randomized users for each test. If these users are part of an organization, you create a random organization, ect.
This isn't always possible. Some applications are designed with implicit singleton resources in the code. In this case you'll have to refactor the application to make these resources explicit.
Alternatively consider pushing your Cucumber tests down the stack. You can test business logic at any abstraction level. It doesn't have to be an integration test. Then you can use JUnit with Surefire instead and use Surefire to create multiple forks.
I'm using JMeter for integration and non-regression testing.
The tests are automated and reports are working.
But since it is scenario testing and not performance testing the report doesn't give real business added value for that kind of tests.
My question: Is there any way to have a scenario (transaction controller based)reporting?
For the moment, to have some more meaningful result, transactions controllers and dummy sampler are used.
What we would like to have is the number of success/failure scenarios of the last test run. And also an history of success/failures per test run (1 by day).
Thank you for your advices.
The easiest way of getting the things done is putting your JMeter test under Jenkins orchestration so it will be automatically executed based on a VCS hook or according to the Schedule
Once done you will be able to utilize Jenkins Performance Plugin which adds test results trends charts and ability to mark build as unstable/failed depending on various criteria.
If I am not wrong, you want to create a suite based on particular test cases. like if single case include execution of more than 1 request in a single execution.
If this is the case, you can simple create a test fragment through jmeter gui, and copy all the samplers in single fragment.
Now to control their execution you can use any controller of your choice, i would suggest you to use module controller for http samplers.
I am running some unit test that persist documents into the MongoDb database. For this unit test to succeed the MongoDb server must be started. I perform this by using Process.Start("mongod.exe").
It works but sometimes it takes time to start and before it even starts the unit test tries to run and FAILS. Unit test fails and complains that the mongodb server is not running.
What to do in such situation?
If you use external resource(DB, web server, FTP, Backup device, server cluster) in test then it rather integration test then unit test. It is not convenient and not practical to start that all external resources in test. Just ensure that your test will be running in predictable environment. There are several ways to do it:
Run test suite from script (BAT,
nant, WSC), which starts MongoDB
before running test.
Start MongoDB on server and never shut
down it.
Do not add any loops with delays in your tests to wait while external resource is started - it makes tests slow, erratic and very complex.
Can't you run a quick test query in a loop with a delay after launching and verify the DB is up before continuing?
I guess I'd (and by that I mean, this is what I've done, but there's every chance someone has a better idea) write some kind of MongoTestHelper that can do a number of things during the various stages of your tests.
Before the test run, it checks that a test mongod instance is running and, if not, boots one up on your favourite test-mongo port. I find it's not actually that costly to just try and boot up a new mongod instance and let it fail as that port is already in use. However, this very different on windows, so you might want to check that the port is open or something.
Before each individual test, you can remove all the items from all the tested collections, if this is the kind of thing you need. In fact, I just drop all the DBs, as the lovely mongodb will recreate them for you:
for (String name : mongo.getDatabaseNames()) {
mongo.dropDatabase(name);
}
After the tests have run you could always shut it down if you've chosen to boot up on a random port, but that seems a bit silly. Life's too short.
The TDD purists would say that if you start the external resource, then it's not a unit test. Instead, mock out the database interface, and test your classes against that. In practice this would mean changing your code to be mockable, which is arguably a good thing.
OTOH, to write integration or acceptance test, you should use an in-memory transient database with just your test data in it, as others have mentioned.