I'm trying to figure out how to configure RESTeasy for use with Mockito. I had to create custom Serializers and Deserializers. I found this article that talked about creating custom serializers and deserializers and turning them into a module.
I also found this article and this article about configuring Jackson to use the new custom module that I wrote.
The problem that I'm having is that I don't know how to test it. One of the articles says
The answer is to have Jackson(Jaxb)JsonProvider in the resteasy.providers section of resteasy-jaxrs.war/WEB-INF/web.xml
I'm using Mockito to test everything. As far as I know, there isn't a resteasy-jaxrs.war file that is made. Is there anyway that I can fake this?
I should probably also add that I'm using spring and I have an applicationContext.xml file that I use just for creating fake beans etc. for testing.
If you want unit tests REST application go with REST-assured. It is very simple and powerful library - you don't need to mock everything. For other options see Ways to test RESTful services?.
Remember that even if you manage to mock everything, such test might be hardly useful - you'll test your mocks, not a true application.
Related
I want to automatically document my REST-API. I know, there are many tools for that, but I want to generate the documentation from my unit tests.
The reason for this is, that I want the documentation to mirror, what is tested and what not. Nevertheless the documentation should be as rich as a documentation generated by let's say swagger.
I already found two projects with this approach, doctester and testdoc4j. Both do not satisfy my needs. The resulting documentation does not aggregate the happy path and the error paths.
What tools do you use and can you suggest any good one?
Cheers.
Edit:
There is a difference between documenting the API contract, defined in the interface, and documenting the test scenarios. If my documentation only includes the tested endpoints and pathes, I am able to define my interface and can hand out only the portions, I have tested.
This means I am able to define an interface with let's say ten endpoints. After implementing a basic functionality with corresponding tests, I can release this part with documentation. Not yet stable or implemented endpoints are not included, which prevents the users from using them.
Perhaps you want a BDD framework? Eg:
cucumber
fitnesse
jbehave
I recently did some research about the same topic and decided to use the free version of Miredot because it is the only tool that fulfilled my requirements:
Does not need extra annotations. All information is extracted from JavaDoc
Can handle JAX-RS as well as Spring annotations
Easy maven integration
Miredot generates automatically a HTML based documentation when you run mvn test
Swagger is a beautiful option. It's a project on GitHub, has Maven integration and loads of other options to keep it flexible.
Integration guide: swagger-core wiki
More Information: here
Not sure if you have already found something for this, but Spring RestDocs does exactly what you are asking about here.
https://spring.io/projects/spring-restdocs
Im curious as to other tools you may have run across in other languages too.
The play documentation about functional tests in java shows two modes
using fakeApplication to specify a custom configuration (in memory database in the example)
using dependency injection to configure the application
I would like to use dependency injection but I have to set custom configuration on application startup like the use of in memory database.
I cannot achieve to do that. I guess this has to be done in the guice builder but I don't know how.
I am assuming you are using Guice for DI.
The discussion on issue 4809 on the framework's github repo should help on answering your question.
I was able to make it work using one of the solutions on the issue:
new GuiceApplicationBuilder()
.configure((Map) Helpers.inMemoryDatabase())
.in(Mode.TEST)
.build();
I'm currently working on a project that involves building a REST api using JavaEE. The setup of the project is Tomcat, Hibernate, Wink and Jackson Json for the different json-views. At the moment the unit testing of the rest resources is very poor, we've written custom classes that using introspection find the method that corresponds to a given resource but it is getting in our way (all the workarounds that we need to do in order to execute a simple unit test). I did a little research and found this.
My question is how to "install(add)" the MockServletInvocationTest class and its dependencies to the project? We're not using Maven, nor Spring. Is there a way to use Spring modules (I think this mock class is in the Spring test-module) outside Spring and if yes, how?
I found a solution, so for those who are interested: just add the following jars to your WebContent/WEB-INF/lib:
spring-test-xx.jar
spring-core-xx.jar
wink-component-test-support-xx-incubating.jar
commons-logging-xx.jar
And everything workds fine.
Is is possible to declare mocks using some mocking framework for my own classes declaratively with Spring? I know there are some standard mocks available in Spring, but I'd like to be able to mock out my own classes declaratively too.
Just to check I'm not going about this the wrong way: the idea is to have a pair of JUnit test and Spring config for each integration test I want to do, mocking everything except the specific integration aspect I'm testing (say I had a dependency on two different data services, test one at a time) and minimising the amount of repeated Java code specifying the mocks.
I did it using special context.xml that included the real XML and overwrote definition of the special beans. Id'd be happy to know that there is better and smarter solution but this one worked fine for me.
Seriously - you really dont want to be doing that.
I have seen a number of projects that attempt to do this and i promise that you will end up with
A huge number of spring files, each one slightly different, but you don't know what and why.
Spaghetti code, because the "declarative" definition doesn't allow to figure out that your objects are doing too much, or doing it with the wrong collaborators.
In the system case, there are a number of points at which you can stub out external services...
I would recommend that you read GOOS - It devotes a book to answering this kind of question.
http://www.growing-object-oriented-software.com/
If there is only a few beans that you want to change, and you want to change them for all tests, the you could have a look at the #Primary annotation.
You have to annotate the special class for the tests with #Primary - then it will "override" the real class. -- But use this only if you want to do it for all tests.
I'm writing a java library that will be used by an existing application. I'm using dependency injection so testing is easier, and I'm familiar with Spring so I was planning to use it to manage the dependency injection while testing. The applications that will eventually use the library are not Spring-based, however, nor does it use any IoC/DI container of any sort currently. My question is, what's the best approach for injecting dependencies if Spring or Guice are not used? Should I consider something like a factory method to instantiate and wire the objects? The dependencies are all inside the library, so it doesn't seem appropriate to have the application instantiate each dependency to create the main object.
what's the best approach for injecting dependencies if Spring or Guice are not used?
If your library was written in a DI-friendly idiom. It should be fairly easy to use as a straitforward java API. Think of your past experience with spring. There are several libraries out there that fit perfectly with the spring model but were written before spring time. I don't see nothing bad with a new followed by a couple of setXX followed by a call to the real work method. Just be extra careful, since, among other things, your client can forget to call thouse init methods that spring reliably calls.
Should I consider something like a factory method to instantiate and wire the objects? The dependencies are all inside the library, so it doesn't seem appropriate to have the application instantiate each dependency to create the main object.
Let the client application decide that. You are providing a library. Let the API client wire its own objects. Provide an example. Later, that same example can be used to make the factory method on the client's domain. Maybe the client application has it's own way to configure itself, and it would be desirable if the API your library provides to be flexible enough to take advantage of that.
Or maybe you can include guice. The licence is Apache. Just like a whole piece of Java itself.