I want to run my JUnits on demand via RESTful api. These are primarily the functional JUnits which test the RESTful endpoints, so they don't directly test source code.
Is there any tooling available to scan existing JUnits and provide those a list of available tests along with the ability to execute those tests.
I am thinking of something which similar to the following REST calls --
GET unit-test-service/tests (to get the list of tests)
GET unit-test-service/tests/123456?execute=true (to execute the test and return test result as response.)
Any pointers are greatly appreciated
Try using Fitnesse it is a simple wiki based testing tool having test classes in Java or other languages. It also has the REST urls where you can retrieve test cases as xml and parse it or run it as well.
Related
Please help me to pick up the right approach for testing REST API (Java).
I've used JUnit and Mockito in my previous project(s) and I know it demands a lot of time/efforts to get enough code coverage. But recently I came to know about Rest-Assured and it seems promising. Please suggest based on your experience.
JUnit in this instance is a runner. This question is really about the difference between unit testing and integration testing, both of which can be implemented using JUnit as the surrounding execution framework.
There are many combinations of framework you could use. Some common ones:
JUnit + mockito for unit testing - where your REST API controller beans are wired up to lightweight/mocked dependencies and you execute the API through JAVA
JUnit + Cucumber + RESTAssured for integration testing - where you write a test fixture that expects to execute against a running server in order to exercise its API
There are points between these extremes too. You have to decide where your tests sit on the test pyramid. For highly permutational tests, you will want to write unit tests in order to be able to achieve the permutations easily and get speed of execution. If you're really trying to smoke test that your APIs are available, having already unit tested them, then you'll want to write a small number of integration tests.
In between the points of the spectrum there is a combination of mockito + the native test library of your service. For example, in Spring there's SpringTest and in Jersey there's the JerseyTest/Grizzly framwork. In these instances, a non-real http server is stood up to host your REST service and you test it by simulated REST calls to it, through the framework's client. This unit tests the HTTP marshalling layer as well as the first layer of REST controller code.
Normally, when I implement new features, I write corresponding automation test code. But right now we are working on a special project. I don't know if it is good practice to write automation test code.
The project is a legacy project, which doesn't have automation test code. The functions are stable they been there for years. We do not add any new functions to it, and we probably won't in future. We need to change the UI from flex to html, so we need to change the way how we expose APIs. We used to expose API through spring remote. Now we switch to RESTFUL APIs. In other words, we only write wrapper code. We don't write if...else.. or loops. Is it a good practice to write automation test code for the mid-tier in such case?
Yes.
A unit test could verify the parameters passed to the API were correctly passed on to the wrapped component. In this case the wrapped component might be mocked.
An integration test could verify the API (facade) correctly wired the real components, and assert the expected result.
I am a Java developer. We want to use cucumber testing in our project. We are working mainly on creating APIs. I am good with unit testing and researching about cucumber.
I am thinking about testing persistence methods - CRUD operations as an starter. My questions is that what could be the scenerios in this testing.
Also should I mock the database by creating tables in the feature file. Should I use mockito with Cucumber to mock call to some other services which connects to database and server.
What should be the cucumber testing in these scenerios and whats the best way to create framework to use cucumber in our Java API's project.
Also, how to populate models if not using database
IMO Gherkin (the language you write Cucumber features in), is good for writing business readable, simple scenarios.
To answer quickly, I would say that Cucumber is not a good fit for testing methods, if it is what you want to do.
As you can see with the file naming convention, you write *.feature files, and I think these files must only contains feature-related descriptions.
However, if you do have features to test, you have to choose how to test them
disconnected, can be run quicky by your CI
you will have to mock everything that cannot start-up in the build lifecycle
and they are solutions to start almost anything using Docker, like Testcontainers
connected to a environment
you do not have to mock anything
your tests may be slower
your tests may break because of the environement (failed deployement, server down, etc.)
I am making an framework that internally uses REST Assured. This framework will have the 4 #Test methods for CRUD operations. These methods are called individually by the user. I want the method should generate the JUnit report for each test case which the user calls(GET/PUT/PUT/DELETE).
I tried using surefire-report plugin. As I have read, that will generate report only when we build the project(running all the Test suite)(please correct if I am wrong).
I want particularly my framework should generate the JUnit style report(for jenkins integration) at the end of each call. I used the ExtentReport, but thats not what I wanted actually.
Please suggest any way to get the work done.
I am using an external library in a java project but I am not sure how can I integration test it with my code.
For example: Let us say I am using a string encryption library to encrypt passwords.
Please enlighten.
Thanks
You are probably thinking of integration testing, not unit testing. Generally I don't unit test code that isn't my own. What I would do for integration testing is basically write tests similar to my unit tests for my code, but not mock out the external library -- i.e., use it directly. You may need to do some set up to create a test environment, including any data you want to use in the test, in which to carry this out. The integration tests may be less extensive than your unit tests since you really only need to test the paths that exercise the external functionality, not necessarily all paths through your code.