My application is in scala using akka and consume web services. I want to write test case for same but not exactly understanding which tools and technique to use. I am new to scala.I am told to mock webservice calls using (mockito), pls guide any working example or some hint.
I will request to look Resito - Inspired by Mockito. It will pretty easy to mocking web service read more
You can create simple web Serivce that already consuming by scala application and point scala application to mock service and check how it behave.
here is all example : https://github.com/mkotsur/restito/tree/master/examples
Please let me know if you have any question.
Mockito is also good but it is more easy to use Resito as it will create stub server and other thing easily.
Related
I have a simple Java application (Not a web application) and using maven I distribute it through a Jar file. I need to expose some of its public methods through HTTP(Similar to rest APIs) so that other applications can reuse it by making rest calls.
Doing some research I see for example, Jersey is an option but that seems to be only available for Java Web applications. I also came across HTTPComponents + HTTPClient but the code is much more complicated than how Jersey is.
My question is whether there is a simple solution for Java applications to expose public methods through HTTP.
Thank you,
Sara
Please refer to the comments for the answer. Multiple Web technologies were suggested and seems like I have to convert the project to Web based application if we'd like to distribute as rest APIs and otherwise, if user agrees just use the Jar and Java APIs. Thanks.
I have to automate REST API testing in my project and integrate it in to existing CI in jenkins.
I am about to start coding using REST-assured.However I happened to see SOAP UI REST tutorial and understand that there is a maven plugin in SOAP UI to help jenkins integration. Before I progress, just wanted to know if there is an obvious advantage to using SOAP UI over Rest-assured.
I have to complete the automation of around 30 requests with complex JSON responses in about a month - including schema validation for responses.
I haven't used REST-assured, but I had a quick look and I see it's a java DSL for testing rest services. Given that it does what it says it does, here's my answer...
I've used SOAP UI for testing of web services. Generally, SOAP UI has been very good for manual testing, but I found it difficult for automated testing.
The main reason was that many of the file paths are hard corded into SOAP UI projects, and so a project referring to c:\development\myproject\wsdl\myservice.wsdl would suddenly not work on another developer machine at /dev/myproject/wsdl/myservice.wsdl.
I also found not being able to effectively edit the SOAP UI projects in intellij meant I was constantly alt-tabbing.
Yes, the soap ui maven plugin did work, but I found it cumbersome.
Note that I haven't used SOAP UI REST, just "normal" SOAP UI, but if your use case is purely to implement automated testing, and that the REST-assured framework does what it says, I would certainly recommend to use the DSL.
Given your current use case, the simplest among the 2 would be to use rest assured (+points to java dsl; bonus readability for testing; but you can always use other clients if you want to). Given that you intend to automate your test and integrate it on CI, you can simply create a module which runs your test suite on a given phase and gather the results.
PS: i currently use jbehave + rest-assured
I like Play 2.0 much (especially Scala API). But it lacks SOAP completely. Is there some not mindblowing way to provide SOAP WS (wsdl based) from Play 2.0?
Say, I'd want it to be accessible from some URL (e.g. /soap), preserving other pages to be HTML. Please, help, I have no clue (I'm java newb, and zillions of abbreviations for frameworks and libs make me confused).
PS To prevent possible unproductive treatments: I'm a java newb but not a newcomer programmer, so I know how SOAP, HTTP and other stuff are meant to work at protocol level.
I ran into the same problem - Apache CXF and Axis2 depend on the Servlet API, which the Play Framework doesn't have.
I created a custom transport plugin for Apache CXF which connects to Play's Controller API.
There is a tutorial about setting it all up in an empty project: http://www.imind.eu/web/2013/11/07/developing-soap-services-using-play-framework-2-2-x/
The plugin's source (and a sample Play application) is here: https://github.com/imindeu/play-cxf
If you trying to create a web service API for existing business logic that will be part of your Play service, then you should probably look using existing Java libraries that can do the SOAP magic for you (e.g. Axis2). Scala can use existing Java libraries without any problem.
However, most people would strongly recommend you look at a REST service rather than a SOAP service, if this is an option. Have a look at Play Mini to see how this is done.
UPDATE:
Ah, this may help you: https://github.com/mandubian/scala-xmlsoap-ersatz
Web services are used to share the services provided by an application, to outside world. This is my basic understanding of web services.
Suppose my application is to expose some specific behaviors and I have written the code for it and exposed the methods. The ones who want to use it can take the link to the wsdl, generate stub and call the methods.
What is the use of doing all this, when I can myself expose the methods, generate a jar and bundle everything in it and share the server address,jar.
How differently is web services important, when compared to a case explained above. Am asking such a general question due to unsuccessful search in many websites.
If you'd generate a client jar, whoever wants to use that would have to deal with Java. If you expose a Web Service instead, the user can use whatever technology he/she wants to use (e.g. Python, Ruby, .net, C, C++ etc. etc.). That would be a huge advantage.
Web service use a series of standards(SOAP, WSDL...) to make different kinds of system work together, certainly you can generate client jar as you like, but that requires your service consumer to learn how to play with it, so it's not a generic solution.
What you are suggesting is quite close to RESTful webservices. Unlike SOAP webservices, RESTful webservices do not require any WSDL files. All that you need to do is to issue a request to a particular URL.
As you explained correctly (in my opinion) SOAP webservices involve some more work which needs to be done, thus making them more complex, if you will, to integrate with other systems. This is not the case with RESTful webservices.
EDIT: You can check out a tutorial here. I have tried it myself a while back and it is enough to get you started.
I need to write a web service client in Groovy. The author of the web service has proposed various unappealing blobs of Java code that I could use to call the service from my Grails application.
At this point, I think it might be better if I just ask them to give me the WSDL and I'll take care of the client code myself. I'm looking for suggestions about the best way to go about writing a Groovy web service client using only a WSDL document?
I expect most suggestions will involve using some tool to generate a client-side API that I'll call from my Grails app. If so, then it's important that I can integrate generation of this API into a Grails build, because the WSDL document will probably change frequently.
I've looked at using GroovyWS which provides a very simple way of calling web services. However, it seems to lack any concept of a contract which concerns me from the point-of-view of testing. I would like to define a contract (interface) for the web service, for which I provide a real implementation that the app will use and a mock implementation that my unit tests will use.
Given your desire for more stability than the very dynamic GroovyWS, I'd suggest the easy way:
Use JAX-WS to generate a Java client, compile that and use it from Groovy. It's all statically typed and the generate Java source is reasonably clean (definitely much better than older WS client frameworks such as Axis 1).
Of course that would require that you have access to the WSDL.