Closed glebec closed 6 years ago
This seems worth the occasional "what is this" from students. Creates a learning opportunity for more inventive uses of testing.
Breaking seed files is a real issue during Sr. phase projects and this will prevent a broken seed from infecting master, which can create a full-team blocker.
Fixed indentation & resolved lockfile conflicts. (Sorry about weird merge, thought that a push had failed and did a local reset before I realized a commit had made its way upstream after all.)
Couldn't we just module.exports = seed
, require it into the test and assert that the promise it returns doesn't reject? Using cp here seems kind weird.
@tmkelly28 the seed file as it exists currently runs the seed
function upon require
/ initialization. That script shuts down the database connection at the end, so you cannot both require the seed script and invoke seed
directly in tests. I think this may also have implications for running the seed module alongside model tests, but I cannot recall if I actually ran into that as an issue or not.
We could wrap the existing call to seed
in a if (module === require.main)
check. That is a tiny bit more novel/complex for students, but probably how I would do this "for real."
I think at the time I was also just thinking that as a simple sanity check, I didn't want to tie the test to the seed file implementation at all – just know if it was even possibly to run the module successfully. I suppose that directly require
ing the module would provide the same information.
Ultimately I'm having trouble remembering why precisely I did it this way, I could be overlooking something that occurred to me at the time – or I could have just been using a hammer where a scalpel is more appropriate. I'll refactor this to use the seed
function directly.
Lockfiles will be the death of me. Had to re-generate this one from scratch.
Assignee Tasks
Closes #79