Can you please elaborate the part "You can have an endpoint that you pass an XML or JSON document to describing the database state, and have the backend set up the data correctly" on item #2 ? Especially the difference between #1 and #2. What can be the content of "XML or JSON document describing the database state"?
Imagine you are writing a Blog. You're standard API will give you:
Create Post
Edit Post
Delete Post
Comment on Post
Edit Comment
Delete Comment
When you are testing that retrieving a Blog Front Page - which gives a list of all posts, and includes the number of comments on each post - works correctly, you can seed the data by:
Finding all posts and deleting them
Creating the new posts
Creating the new comments on the posts
If we are testing a front page that has 5 posts, with 5 comments on each, this will be 30 requests + whatever is needed to delete the existing data. And if any of those are broken then this test will fail.
Alternatively you could have a single endpoint that is only accessible by the tests - it absolutely must be locked down so that it can never be accessed by a real client - that you send a model of the data to and it makes the database have the correct data.
For the same test as above, you would make one request to this endpoint with one document, and this document would contain all of the posts and comments. The backend would then process this and make the database contain only the data in this document.
The end results are the same, but the means to get there are very different. One puts the burden on the client - and assumes that APIs exist to make the required changes. The other puts the burden on the server.
Can you please elaborate the part "You can have an endpoint that you pass an XML or JSON document to describing the database state, and have the backend set up the data correctly" on item #2 ? Especially the difference between #1 and #2. What can be the content of "XML or JSON document describing the database state"?
Imagine you are writing a Blog. You're standard API will give you:
When you are testing that retrieving a Blog Front Page - which gives a list of all posts, and includes the number of comments on each post - works correctly, you can seed the data by:
If we are testing a front page that has 5 posts, with 5 comments on each, this will be 30 requests + whatever is needed to delete the existing data. And if any of those are broken then this test will fail.
Alternatively you could have a single endpoint that is only accessible by the tests - it absolutely must be locked down so that it can never be accessed by a real client - that you send a model of the data to and it makes the database have the correct data.
For the same test as above, you would make one request to this endpoint with one document, and this document would contain all of the posts and comments. The backend would then process this and make the database contain only the data in this document.
The end results are the same, but the means to get there are very different. One puts the burden on the client - and assumes that APIs exist to make the required changes. The other puts the burden on the server.
Thanks for the clarification :)