I am developing in a micro services architecture, currently each service is developed in ruby.
One of the advantages of decoupling services is a future ability to refactor a service from ruby to another technology, let's say Node.js
When I will do this refactor some time in future, I would want my integration tests to keep functioning.
Ideally, I would want to develop the integration tests in rspec (ruby), and to keep them functioning on a non-rails server via HTTP.
Is that possible with rspec?
Which tool can provide this requirement?
RSpec is a behavior-driven development (BDD) framework for the Ruby programming language. It is used for unit testing. It can;t be integrated with another tech stack
However, If it is all about doing the integration testing for your web services, I think Cucumber is something that will help you to achieve the same.
Cucumber as a tool is technology agnostic. However, you will have to design your integration tests in such a way that any helper libraries to execute or write the testcases could be easily replaced with the libraries of other language when you are changing you tech. stack for the webservices/test cases.
As long as you test the endpoints exposed by the webservice and not how they are implemented , they should keep functioning.
You could achieve that by writing your integration tests in spock which is a beautiful BDD framework in groovy, using that you can hit the endpoints like
GET /cars ---> Check for the list of cars
POST /cars ---> Add a car
GET /cars/1 ---> Get a specific car details
PUT /cars/1 ---> Edit a specific car
Now when you are testing like this, it doesn't matter what the implementation is coz you are always testing the interface.
Related
I need to automate my web application functionality using rest assured.
Means there are no endpoints to verify the functionality of login module on the homepage and I need to automate same login Page functionality using Rest Assured.
Please, anyone, tell me to know the solution of my this query.
Rest-Assured is just a REST testing tool, you can't use it to perform UI functional testing.
You should use one of the tools dedicated to that, like Selenium.
The best way to go is to split your testing in two separate projects.
Backend functional testing with Rest-Assured (Making REST calls).
Frontend functional testing with Selenium (Using Selenium).
I am developing a system composed of two different rails applications (server and client) which communicate via rest web services.
I have tests for each app individually, but I would like to add some test for the integration between the two platforms, to assert that one creates a request compatible with what the other is expecting.
Any hints would be appreciated.
I have a similar architecture and we are using VCR in order to record all server side responses and avoid make requests always. It could turn annoying and right now I'm looking for a way to clean data from server after every request
I think VCR could be a good start point in order to test integration between your apps.
You can find documentation here -> Relish Docs
I think there could be several approaches here, depending what you have implemented..
If the client Rails app has user interface, try to write Selenium tests to perform the integration test in your local dev environment or a staging environment that has both deployed. (not ideal if the interface is still a prototype, changing frequently...)
Maybe part of the client can be written as a Ruby gem (e.g. the communication rest api is a ruby gem). When the server app in testing environment, the server Rails app can use the Client gem to run integration test, i.e. call the module function, the same function is used by client. The client Rails app can also use the gem to make requests to the server. Here's a good guide to start migrating some of your reusable code to rubygem.
I need some advice about efficient way of writing integration tests for our current ASP.NET MVC application. Our architecture consists of:
A Service Layer below Controllers
Service Layer uses Repositories and Message Queue (sometimes) to send messages to external applications.
What I think should be done is to:
Write behavioral unit tests for all pieces in isolation. So, for example, we should unit test the Service Layer while mocking Repositories and Message Queues.
Same goes for Controllers. So we mock the Service Layer and unit test the Controller.
Finally, we write separate integration tests for Repositories against a real database and for Message Queue classes against real message queues to ensure they persist/retrieve data successfully.
My Questions:
Are there any other types of integration tests that we need to write?
Do we still need to write integration tests for Services with the real Repositories and Message Queues?
Do we still need to write integration tests for Controllers with the real Services (which in turn consists of real Repositories and Message Queues).
Any advice would be greatly appreciated.
Cheers
Here at office we do not test against real services.
We have test in service side
We are testing controllers as unit tests, we use mock in these unit tests
Yet we don't have a integration test :-(
We were advised to not use real services for testing, we use Rhino Mocks to simulate answers for methods being called inside controller actions.
So the problem is still about how to do integration tests in a good way.
Maybe this could help you:
http://www.codeproject.com/Articles/98373/Integration-testing-an-ASP-NET-MVC-application-wit.aspx
but I am still looking for a better understanding about its possibilities.
I'm using Ivonna for testing various levels of isolation. I'm able to test that a particular Url with some particular POST data hits the expected Action method with the expected arguments, and at the same time I'm able to stub/mock external services.
I've been using SpecsFor.MVC for integration testing. Essentially you write code in a test class and the framework runs a browser interpreting your C# into browser actions. It's beautifully simple to use and setup.
Lets say; I am developing a Web Application which talks to a RESTful web service for certain things.
The RESTful web service isn't third party, but is being developed parallely with main application (A good example would be, E commerce application and payment processor; or Social network and SSO system).
In such a system, acceptance(cucumber) or functional tests can be done in two ways:
By mocking out all external calls using object level mocking library; such as Mocha or JMock.
By doing mocking at http level, using libraries such as webmock.
By actually letting the main application make the actual call.
Problem with #1 and #2 is, if API of underlying application changes; my tests would keep passing and code will actual break and hence defeating the purpose of tests in first place.
Problem with #3 is, there is no way I can do rollback of data, the way test suite does on teardown. And I am running my tests parallely and hence if I let actual web services go, I will get errors such as "username taken" or stuff.
So the question to community is, what is the best practice?
Put your main application in a development or staging environment. Spin up your web service in the same environment. Have the one call the other. Control the fixture data for both. That's not mocking; you're not getting a fake implementation.
Not only will this allow you to be more confident in real-world stability, it will allow you to test performance in a staging environment, and also allow you to test your main application against a variety of versions of the web service. It's important that your tests don't do the wrong thing when your web service changes, but it's even more important that your main application doesn't either. You really want to know this confidently before either component is upgraded in production.
I can't see that there is a middleground between isolating your client from the service and actually hitting the service. You could have erroneously passing tests because the service has changed behavior, but don't you have some "contract" with the development team working on that service that holds them responsible for breakage?
You might try fakeweb and get a fresh copy of expected results each day so your tests won't run against stale data responses.
I am building a REST Web Service layer on top of a Rails app that will be used by an Iphone application. The response format is XML.
I would like to build some acceptance tests that should be external to the rails stack (and should test everything, including the http server). The test scenarios are quite complex, involving the process of searching/posting/reviewing an order. What would be the best solution to accomplish this?
a. Ruby script using curl/curb to fetch the request and Hpricot to parse the request
b. Selenium
c. ..
It would also be nice that those tests could be used as integration tests (therefore, run on every git commit). What integration solution would you recommend?
a. Integrity
b. CruiseControl
c. something else
I've used three approaches over this last few years
Active-resource
I found this to be too concerned with looking like active-record to be a great solution. In some cases I had to patch parts of it to work as I'd like a REST client to behave.
Rest-client
This gem is very good - well documented and does works as expected. I combined this with my own simple DSL and it's worked out better than a generic testing framework
XML over HTTP
I use this for performance testing. Very flexible but the learning curve is higher than Rest-client. If you go down this approach you could use the Net::HTTP core class or the HTTParty gem (I haven't tried this but it looks great>
A really good resource is this Net::HTTP cheat-sheet
For ad-hoc testing I've also found the Rest Client add-in for Firefox very useful.
Use selenium-rc in ruby mode and you'll be a happy camper. Webrat/Cucumber already do this for you so you can just put that in a second project and run the tests that way, all you'll have to do is override the host (so instead of localhost you'll be using your domain).
As to CI I'm afraid I don't know the best one.
you can't possibly mean mks integrity...if so, the answer is anything but. CC is a good CI tool. really good.