Using JDBC and a with-transaction has been a lifesaver for testing work, as all test scaffolding is undone after work. However, now I have a function that needs to sort database entries by creation date and am having trouble because, even if I’m sleeping in the middle, the number of database entries are all input at the same time within a transaction, and their database entries have identical “created” dates.
Within my deftest:
(loop [n 1]
(when (> 5 n)
(do
(Thread/sleep 1000)
(subj/create-with-contents tn (str s n))
(recur (inc n)))))
If a test needs specific database setup like that, I just write the test to setup and explicitly teardown the database changes made in the test. I don’t think you can avoid that in this case.
But I would probably question what you’re actually testing here? If you separate persistence from business logic, then you’d have functions to save data and read data – and then separately you’d have functions that produce the data to be saved and to process the data that was read.
At that point you’d be able to test the business logic without touching the database: you’d be able to verify the order that data is produced in and you could create mock data that is in order for some tests and deliberately out of order data for tests of what should happen if your business logic gets “bad” data.