hope you can able to help on my problem. As of now, I can only test transmissions via SOAP UI in single requests, and the thing is I have a lot of data to transmit and it would be too problematic and laborous to do tests one by one.
Is there a way in SOAP UI wherein I can perform multiple requests at once?Appreciate your feedback and input as always. Thanks!
I would recommend using Ready API! SoapUI NG Pro and use the a DataSource test step with a DataSource Loop. The Data Driven Sample Project (available on the starter page of Ready! API) contains a minimal working sample to get you up and running.
Disclaimer: I'm working for the company developing SoapUI and might be biased on the greatness of the Pro version.
Related
we have an existing C++ (STL, boost, Qt4) server application which communicates by xml commands over tcp sockets with the clients. The interface is proprietary, but not so far from SOAP, but with one exception. We have large set of master- and (calculated) project data, which is initialize and calculated at server startup (and updated later on). Building and calculating this data on every service request is much to expensive.
Now we want to port some (in future all) commands to web-services. We found/evaluating the following C++ frameworks:
Staff
gSOAP
WSO2
Roguewave Hydra
Now my questions ;-)
How is the standard way to build a web-service which have access to permanent in-memory project data, which be initialized at server startup (not web-service request)? Are the any resources on the net?
Can above be solved with gSOAP own HTTP Get plugins?
Have i forgot a recommendable C++/web-service framework?
Thanks in advance Lars
memcached or a real database of some sort. Depends really on how much concurrent usage there is and will the dataset be modifiable by multiple clients.
Others, no idea..
I've developed a simple xmpp chat client (for Android, using asmack library). Now, I would like to test the client to see if it does what it is supposed to do (ie. fetch the list of contacts, refresh contact list, receive messages). Using smack library, I assume it is pretty much safe, but still...
How could I check if my fetched list of contacts is the one returned by the server? How to check if the presence status of certain contact is the correct one?
Regarding the usage of unit tests, I was thinking of mocking the server side and test the client side, but that doesn't seem of much use because I would like to test it with real server data.
Is there some automated tool for this? Or would it be enough just to distribute the application to my friends and tell them to use it for a while and report any misbehaviors?
You'll just have to trust aSmack. You could use logcat to investigate the XMPP stanzas returned by the server "by hand" and compare them to your client's behavior. You could also increase the verbosity on your server's log (if you have access) and compare that way. However, doing automated testing would require some sort of XMPP parser - but that's exactly what aSmack is. I'm sure the aSmack developers have already tested it thoroughly enough using their own methods.
I've started using SOAP UI recently to test web services and it's pretty cool, but it's a huge resource hog.
Is there any way to reduce the amount of resources it uses?
It shouldn't be a resource hog, although I've seen it do this before. I leave it running on my PC all week, and a co-worker with a similar machine (dual-core running XP) has to kill it every few hours, otherwise it keeps using CPU. I'd try uninstalling/re-installing. Currently, my instance has been up for 10 days, running a mockservice that I've been hitting very hard (I've sent it thousands of requests). CPU time total (over 10 days) is about an hour and a half, but the "right now" number is about 1%.
There are no popular alternatives, aside from writing your own client in the language of your choice.
If you're testing WCF services, you can run wcftestclient from the Visual Studio command line. It works for local or remotely hosted services. Its no good for ASMX-style .NET 2.0 SOAP services though.
if you want to test using only json, you could use some of the light weight Rest clients ex. Mozilla Rest plugin.
We test our SOAP APIs manually with SOAP UI and otherwise use jMeter for automated SOAP API testing. While having a GUI seems attractive first, I find both applications quiet user-unfriendly and time consuming to work with.
As already suggested, you could do it in code using Java or maybe use a dynamic language like Ruby:
Testing SOAP Webservices with RSpec
SOAP web Services testing in RUBY
As user mitchnull mentions in his comment:
Disabling the browser component (-Dsoapui.jxbrowser.disable=true)
solved the 100% CPU usage issues for me. (when it was enabled, it
periodically went to 100% CPU even when not running any
tests/requests).
In a normal client/server design, the client can execute functions implemented on the server-side. Is it possible to test a gSOAP server by connecting an extra client to it?
I have not used gSOAP, but from reading the documentation it allows you to write both clients and servers so you can write an test client to test the service.
However if you are planning to offer the service to clients written in .net or java I would recommend that you write the test client in one of these. This way you will know for certain that it is possible to use the service from one of these clients. You might also find that .net or java clients are easier to write if you server is designed in a specific way, your test client will help you find this out.
Sure it is, use SoapUI to generate client connections and data. Its free.
To add to the other comments: testing a gSOAP server can be easily done offline using IO redirect. When you invoke soap_serve() without any sockets set up prior to this call, the server engine will simply accept data from standard input and write data to standard output. This is a great way to hit an offline server implementation hard with XML data patterns for testing before deploying the server online. The gSOAP tool even generates example XML messages that you can use for this purpose.
I develop industrial client/server application (C++) with strong real time requirements.
I feel it is time to change the look of the client interface - which is developed in MFC - but I am wondering which would be the right choice.
If I go for a web client is there any way to exchange data between C++ and javascript other than AJAX <-> Web service <-> COM ?
Requirements for the web client are: Quick statuses refresh, user commands, tables
My team had to make that same decision a few months ago...
The cool thing about making it a web application would be that it would be very easy to modify later on. Even the user of the interface (with a little know-how) could modify it to suit his/her needs. Custom software becomes just that much easier.
We went with a web interface and ajax seems the way to go, it was quite responsive.
On the other hand, depending on how strong your real time requirements are, it might prove difficult. We had the challenge of plotting real time data through a browser, we ended up going with a firefox plugin to draw the plot. If you're simply trying to display real time text data, it shouldn't be as big an issue.
Run some tests for your specific application and see what it looks like.
Something else to consider, if you are having a web page be an interface to your server, keep in mind you will need to figure a way to update one client when another changes the state of the server if you plan on allowing multiple interfaces to your server.
I usually build my applications 2-folded :
Have the real heavy-duty application CLI-only. The protocol used is usually text-only based, composed of requests and answers.
Wrap a GUI around as another process that talks to the CLI back-end.
The web interface is then just another GUI to wrap around. It is also much easier to wrap a REST/JSON based API on the CLI interface (just automatically translate the messages).
The debugging is also quite easy to do, since you can just dump the requests between the 2 elements and reproduce the bugs much more easily.
Write an HTTP server in your server to handle the AJAX feedback. If you don't want to serve files, create your server on a non-standard port (eg. 8081) and use a regular web server for the actual web page delivery. Now have your AJAX engine communicate with the server on the Bizarro port instead of port 80.
But it's not that hard to write the file server part, also. If you do that, you also get to generate web pages on-the-fly with your data pre-filled, if you want.
Google Desktop Search does this now. When I search my desktop for 'foobar', the URL that opens is this:
http://127.0.0.1:4664/search?q=foobar&flags=68&num=10
In this case, the 4664 is the Bizarro port. (GoogleDesktop serves all the data here; it only uses the Bizarro port to avoid conflicts with any web server I might be running.)
You may want to consider where your data lives. If your application feeds a back-end database, you could write a web app leaving your c++ code in tact -- the web application would be independent and offer up pages to web users and talk directly to the database -- In this case you have as many options, and more, as you have indicated.