UMM-CSci-3601 / 3601-iteration-template

This template repository is used as a starting point for course projects in CSci 3601: Software Design and Development at the University of Minnesota Morris. It includes an Angular client along with a Javalin server and Mongo database.
MIT License
0 stars 9 forks source link

Use mocking/spies to eliminate calls to the DB in server tests #1391

Open NicMcPhee opened 8 months ago

NicMcPhee commented 8 months ago

I'm not sure if we would want to do this, and would love feedback.

Currently our Java server tests actually require the Mongo DB to be running. This is good in the sense that we're really checking that, for example, our Mongo queries are correct. This is bad in the sense that you don't want unit tests to depend on other stack elements, and it would be nice (and faster) to be able to run the tests without having and setting up Mongo.

An alternative would be to use mocking/spies to replace the calls to Mongo with fakes and have them return what the database would return. That might be tricky, though, because we could write totally busted mongo queries, and mock things so that we return the desired result when using those broken queries and the tests would pass, even though the code clearly won't work. That would hopefully be caught by the e2e tests, but no promises there.

Thoughts about this?

willster000 commented 8 months ago

It sounds like the benefit of this change is that you wouldn't need mongo to be set up/running in order to run these tests. But I can't imagine you would really care about running these tests if you didn't have mongo set up... maybe I'm wrong about that. And getting mongo running is a slight inconvenience but as I student I actually appreciate being forced to run different tools over and over because helps be become a more fluent programmer. For these reasons I think keeping things as they are is a good idea.

NicMcPhee commented 8 months ago

Thanks @willster000 for the feedback. The more I think about this, the more I think this was a silly idea, TBH. Some of that is the reasons you gave, and some is just the complexity of trying to meaningfully mock the DB. If you wanted to have a test that used a complex query, for example, it's hard to know if that query is right if you don't actually run it past the actual database.

I'll leave this here for a bit, but unless someone else is keen I'm likely to close it in a day or two.