0

I'm testing REST API end to end and when I want to check the application behaved. One is using existing REST API where possible but in other cases I don't have REST API available so have two options: creating an api for tests purposes or checking in the database the data have changed as expected.

Which one is better and why? Is there any harm in doing db calls from your tests?

ttati
  • 417
  • 3
  • 9
  • Possible duplicate of [Why should a developer use web services instead of direct connections to a db?](http://stackoverflow.com/questions/2142070/why-should-a-developer-use-web-services-instead-of-direct-connections-to-a-db) – Lenar May 12 '16 at 02:33
  • The question above is not exactly the same than the one you liked. What I am asking is related to E2E testing frameworks. is it better for the E2E test framework to connect to a DB to check the result of a test of it is better to use the application API or even create ad-hoc api in the app for tests purposes? – ttati Jun 08 '16 at 14:30
  • Case 1: if you want to test REST API which has crud operations and you want to validate state of data too, go for testDB(would prefer any in-memory database) Case 2: For checking exact state of DB and since you dont have REST API, i would take a dump/snapshot of db and load it in a docker and verify/validate, whenever it needs to be tested with some queries. – Kunal Mar 26 '20 at 18:58

2 Answers2

3

Since you want to test the API itself (E2E testing) I would probably go with the route of creating a test DB and working on that. If you are performing this manually you can easily, albeit cumbersomely, reset the DB after each test.

You can also, and I would probably go this route, create a Docker container with a ready to use DB that you would update as needed, along with the development of the API itself across time. You could spawn a new container/DB every time you need to perform testing and this would also ease automation and integration in CI/CD pipelines.

Any of these solutions enable you to test the real API, in a real DB. Providing more accurate test results.

Hope this helps! Cheers!

Pedro Filipe
  • 995
  • 1
  • 8
  • 17
1

In e2e tests or acceptance tests you usually only check the observable behavior, so the behavior the user would be able to see, in your case the user of the API, so in theory you should not need to check the database.

If you really want to check the results in the database I would use a project like xmysql https://github.com/o1lab/xmysql to have an Rest API that can be used to check the DB. Reasons are:

  1. you don't have to maintain your own code that serves API endpoints that are not needed in production. That code might get public and might become a security issue
  2. you don't need to mock any database or calls, you can test what you fly, and fly what you test
  3. its easy to test if the system where you run the tests and the system-under-test are different computers. You can test all remotely without needing to open ports to you DB. e.g. its easy to use docker to set it all up, run the tests and then deploy. The only thing the deployment does not have is xmysql
INDIVIDUAL-IT
  • 426
  • 3
  • 11