0

I am going to write a new endpoint to unlock the domain object, something like:

../domainObject/{id}/unlock

As I apply TDD, I have started to write an API test first. When the test fails, I am going to start writing Integration and Unit tests and implement the real code.

In API test, I need a locked domain data for test fixture setup to test the unlock endpoint that will be created. However, there is no endpoint for locking the domain object on the system. (our Quartz jobs lock the data) I mean, I need to create a data by using the database directly.

I know that in API test, straight forwardly database usage is not the best practice. If you need a test data, you should call the API too. e.g.

../domainObject/{id}/lock

Should this scenario be an exception in this case? Or is there any other practice should I follow?

Thanks.

skynyrd
  • 942
  • 4
  • 14
  • 34
  • 1
    I think that in some scenarios when setting up is particularly difficult/costly it's acceptable to either rely on some test data, or even better - try to insert it through the backdoor. That is, when you're testing (any) other scenario that the actual insert/creation one. In your case it might be ok, if there's no way to control/wrap the Quartz (jobs) functionality – Alexandru Marculescu Jun 24 '16 at 08:42
  • yes, using backdoor can be acceptable,thanks. However, I didn't create an api test for this functionality as we have also acceptance testing (selenium), that can cover it. – skynyrd Jun 24 '16 at 11:16

1 Answers1

0

There is no good or bad practice here, it's all about how much you value end to end testing of the system including the database.

Testing the DB part will require a little more infrastructure, because you'll have to either use an in-memory database for faster test runs, or set up a full-fledged permanent test DB in your dev environment. When doing the latter, it might be a good idea to have a separate test suite for end-to-end tests that runs less frequently than your normal test suite, because it will inevitably be slower. In that scenario, you'll have preexisting test data always present in the DB and a locked object can be one of them.

If you don't care about all this, you can stub the data store abstraction (repository, DAO or whatever) to return a canned locked object.

guillaume31
  • 13,738
  • 1
  • 32
  • 51