Persist DB between tests in Codeception

Question

I'm testing a CRUD application written in L5 using Codeception acceptance tests. I was wondering how you guys go about this.

I originally thought I'd be able to use a CEST and use the @depends property to specify the order but it seems the auto DB cleanup is ran after each test, so after my insert the next test can't find that record in the DB.

Is there a way I can do this without specifically making up a DB dump specifically for testing?

I was hoping to be able to have the following tests in this order:

• Create Item
• Read Item
• Update item
• Delete Item

and check the DB at each stage to make sure it was successful.

Any help would be greatly appreciated.

Cheers, Daryll

Answer 1

The default behaviour specified here is definitely what you want. You want the tests to be able to be performed in isolation. If you want to retest an area again, because it is broken, you don't have to go back and run your previous tests again to get it in the correct state to run the tests again.

A single broken test will give you a better idea of where the breakage is, rather than having multiple broken tests because a test that all your other tests depend on was broken, which is what the approach you are describing lends itself to.

If you think about it, say you are doing test driven development. You write a breaking test with the correct data that Creates a record. The other tests are to read, update, read again, delete the record, update a different record, create another new record, and read again. The delete fails, and the create and read tests fail because you reinsert the same index. The tests wont tell you that however, you just get 4 broken tests, and you will have to check all of your tests that are broken, and which one caused the other tests break, if that is indeed the case. You wont know.

If you do what the default behaviour tells you to do, you will have just the one broken test, and you fix the issue. Dead easy. You just add to the database as test cases arise to accommodate for them.

If you want to check what's in the database, you can do that by querying twice in the same test. Perform your update query then run your select query on what you have just done, and do and equals as another assertion. You can trust that the database has ran your query if you set it up correctly and get no errors, but you know your application better. Maybe you have triggers running, for instance.

I believe you can stop the behaviour with this sort of thing in a config, but its not what you want!:

class_name: FunctionalTester
modules:
    enabled: [Filesystem, FunctionalHelper, Laravel4, Asserts]
    config:
        Laravel4:
            environment: 'testing'
            cleanup: false