Test output organization makes it difficult to insert tests

[knex]

Test output organization makes it difficult to insert tests

[tgriesser]

@jblebrun - if you do $ export KNEX_DEV=1 like you would with the path for the db config, then the same function which normally verifies the test output when you're running the tests instead dumps the values from the query into the test file as appropriate (you don't need to write any of them by hand, it re-numbers for you)...

So my reasoning was that the organization shouldn't really matter here, it was just so you could look them up when looking at the string output you could jump down to the value output easily since they're named the same.

Let me know if this makes sense.

[jblebrun]

I see. Do you have a procedure for making sure that previously confirmed test results haven't changed? For example, isn't it possible that in developing a new feature, another test output might change unexpectedly, but since the entire output gets re-generated in generating the results for the new test case, you'd have to be on the lookout for that. I suppose visually scanning a git diff of the file would suffice?

It might be useful to other contributors to provide a quick summary of your process (e.g. a README in the test dir) for adding/verifying new test cases, so that others can be sure to follow the same procedure to remain consistent with your process.

[tgriesser]

I figured that visually checking the diff would be quicker and actually less error prone than doing it by hand...

I did have this sort of mentioned in the test FAQ section... though I could probably word it better or put it in a README in the tests dir as you mentioned:

If you're going to add a test, you may want to follow similar patterns, used in the test suite, setting $ export BOOKSHELF_DEV=1 to save the outputs data from the tests into the shared/output.js file.

[jblebrun]

Oh, I guess I should've taken a better look at the FAQ!