0

I have developed two web services. The main service is a RESTful service (using DB), and another UI service that uses the RESTful service.

Say I want to test the UI for now (integration tests), every test will makes changes in the prod DB. More then that, if in the RESTful service, there are one-way functions for security reasons. I mean that functions that can not be revert (Say if mark item as 'done', I can't edit or delete it anymore)?

This things are very logical, the most websites I know have the same situation. All these websites are not testable?

gnat
  • 21,442
  • 29
  • 112
  • 288
nrofis
  • 147
  • 1
  • 7
  • see also: [Staying OO and Testable while working with a database](http://programmers.stackexchange.com/questions/42792/staying-oo-and-testable-while-working-with-a-database) – gnat Oct 08 '14 at 09:17

3 Answers3

4

First of all, you shouldn't be testing against your production database. If you ever need to rerun your tests after the application has gone live (and you will need to do that), you run a serious risk of losing or corrupting data that is vital to the business.

So, instead of testing against the production database, you test against a test database (which should structurally be a copy of the production one). Then you can also add facilities to your test harness to reset that test database to a known state just before or after running a particular test.
This way, you can test the correct (inter-)operation of the two web services.

If the correct operation of the RESTful service can be presumed, you can also opt for a fake/mock of the RESTful service, which gives all the expected responses for the particular test, but doesn't actually persist anything.

Bart van Ingen Schenau
  • 71,712
  • 20
  • 110
  • 179
  • What about the one-way functions? The RESTful service have no implementation of doing this. How the QA will able to revert all his changes? – nrofis Oct 08 '14 at 09:27
  • 1
    @nrofis: The QA environment can use means that are not available in the API, for example by accessing the database directly. The reset function could for example be implemented as restoring a backup snapshot of the database. This obviously can't be done through the services being tested. – Bart van Ingen Schenau Oct 08 '14 at 09:36
1

Since you have to do unit testing for the REST API, I would assume you are using mock objects for those, rather than interact directly with the database. This should give you a framework of proper "valid" responses from the API already - what I'm getting at is that when you test, you should know you're in "test mode" (either through some global environment variable, separate testing environment or an extra parameter you set in the requests r somewhere else in your workflows). So if you are in test mode, your REST API should return mock objects to your client in the response, without affecting your database records in any way.

Since these are tests on the client side, your concern should be strictly to test the client interaction, because proper API behavior is tested by the REST server-side unit tests, so you should assume that the API itself behaves as it's supposed to.

Thyamarkos
  • 378
  • 1
  • 4
0

Given HATEOAS, you only need to change the base URL for your RESTful service to point the UI service to another implementation of it. So set up a staging version of your UI and test it against a staging version of the data service, making that one change.

Pete Kirkham
  • 1,798
  • 14
  • 15