Is testing for REST access necessary/good?

Question

I have made a rest API using django-rest-framework.

I have multiple API endpoints. Some are used for creation of objects, some are used for listing objects, some are used for getting counts of objects, etc.

In my tests, I test each endpoint to ensure that, say, the create endpoint will only accept POST requests. I test the list endpoints to ensure that they only accept GET, and not POST/PUT/PATCH/DELETE. Each endpoint corresponds to a view, which has a setting that determines what requests they allow, but the tests ensure that those settings work. The tests mainly assert a certain status code is returned.

The tests get pretty repetitive. The tests for the comments API is about 600 lines. Is this kind of testing necessary, and/or is there a simplified alternative?

score 2 · Answer 1 · answered Jul 05 '15 at 18:47

This falls into the category of test antipatterns where you are testing the framework/library instead of your own code.

Some tests like this are worthwhile, especially if you're unfamiliar with the framework, and they serve to validate your use of it. Testing it exhaustively, though, is lost effort you could otherwise be spending on testing your application code.

If you really feel a framework or library is shaky and you still want to use it, you'd be better off testing it directly, ie fork the project (assuming it's open-source), add some tests, and make a pull request.

This is a great answer as well - I've never thought about that. Wish I could accept two answers! — dcgoss, Jul 05 '15 at 18:50

score 2 · Answer 2 · answered Jul 12 '15 at 04:01

2

I stumbled across this cool library: django-rest-assured, which seems to take a lot of the boiler plate off of testing this kind of REST access. This makes testing that functionality much more trivial and perhaps even worth your time.

answered Jul 12 '15 at 04:01

dcgoss

2,147
3
20
31

Yes, django-rest-assured was built especially for that purpose (I'm its author). However, while being great for scaffolding a complete test coverage for your API, you should reduce it to the minimum required by your app for sake of simplicity, performance, and maintainability of your tests, as your project grows and matures. – ydaniv Jul 28 '15 at 12:18

score 0 · Accepted Answer · edited May 23 '17 at 11:59

There will always be a fine balance between writing redundant tests and gaining a sufficient level of code coverage for key areas of the system.

As the endpoints in your app will most likely have a lot of moving parts (i.e. response/request parsing, HTTP calls, accessing of data stores etc.), you may find that too many tests can dramatically slow down your test suite.

You will often find that, in combination with lots of standard unit tests (no i/o), a small amount of targeted end-to-end tests will be sufficient. The key is to find a healthy balance between critical code coverage, and a solid performance of your test suite.

There is a great Stack Overflow topic on this, where Kent Beck discusses an efficient test suite:

How deep are your unit tests?

Awesome! Thanks for the link! – dcgoss Jul 04 '15 at 19:00 — dcgoss, Jul 04 '15 at 19:00

Is testing for REST access necessary/good?

3 Answers3