Is it ok to test an external function?

Question

I have a utility function called connectToMongoDB() which connects to MongoDB. Basically, it creates a client for MongoDB and returns that.

I'm making a library and I'm thinking of unit testing the utility functions. The way my unit test would work is by calling the function, then doing CRUD operations on it and seeing if it works.

Is this a good idea, or does this count as doing the testing for the MongoDB package I am using?

For whatever it's worth, I'm using Go 1.17 and not in a main package (my library is not an executable on its own.)

Answer 1

Why do you write unit tests? Because you want to find bugs with little effort and fix them easily, and/or because you want confidence that everything works the way it should or the way it is expected to work.

Unless you are 100% sure that this function will never fail (and you can never be 100% sure), you can do unit tests even for third party code. Moreover, lots of third party code has bad documentation. So you have an additional bit of documentation: You can tell your colleagues "if you want to know exactly what this function does, look at the unit tests, because it passes those". If someone asks "does this function do what I expect if I do X and I expect Y as the outcome", it's great if you can point them to a unit tests that does X and checks that the outcome is Y.

Answer 2

I'm making a library and I'm thinking of unit testing the utility functions. The way my unit test would work is by calling the function, then doing CRUD operations on it and seeing if it works.

Is this a good idea, or does this count as doing the testing for the MongoDB package I am using?

If this would test the utility functions in your library (rather than an imported library), then it's a fine idea. Finding problems there before running larger tests would save debugging time.

As a matter of perspective, I'd call this a configuration test, not a unit test since it'd mainly detect configuration problems with the MongoDB server and the network. It's neither a "small test" nor a "fast test" since it depends on a separate server. (The terms matters for communication, to keep each type of test good at its particular purpose, and to decide when to run each test.)

If you want to isolate a test of your library from MongoDB configuration and network problems, a good technique is to mock out its access to the MongoDB server or else to test against an in-memory MongoDB server. This also speeds up the test so it becomes a "fast test" that's fine to run every time on every code change.

If you're asking about testing the MongoDB server itself, then I'd call that an acceptance test. The purpose of acceptance testing is to test requirements on MongoDB that your project depends on, e.g. to catch problems for your project introduced by new releases of MongoDB. Server changes aren't always compatible, or perhaps your project depended on details that it shouldn't. This is a good place for tests of MongoDB semantics that caused past problems for your project.

Answer 3

As a general rule, do not write tests verifying the behavior of external code. I would never write a test that asserts string.Format("green {0}", "apple") returns "green apple". This is something the vendor or provider of that external code should verify. Keep your tests focused on verifying your behavior and configuration as it integrates with that external code.

For example, say I have a function named string makeFruitGreen(string fruit). Internally it might call string.Format("green {0}", fruit), but writing a test that asserts makeFruitGreen("apple") returns "green apple" is a useful test, because it verifies the behavior of making a fruit green. Calling an external/3rd party function is an implementation detail. If makeFruitGreen("apple") starts returning "red apple" I would want a failing test — even if, internally, the broken function is still calling string.Format. The call to string.Format works. There is a bug in makeFruitGreen that passes "red {0}" instead of "green {0}" in the call to that external function.

More importantly, as it relates to connecting to MongoDB, what you are proposing is not a unit test. Since the test is using a resource outside the current call stack, it is a form of integration testing. This is still a valuable test, but again, do not test that connectToMongoDB() works. Instead, test a higher level function your team wrote that internally calls connectToMongoDB(). Tests like this verify configuration and integration logic in your code, rather than the logic in the external function that connects to a data source.

Answer 4

My two cents:

With a very well defined interface you can mock mongoDB. However you should mock it right. It is a powerful technique, specially to test corner cases such as specific errors, etc.

Try to write integration tests that can connect to a real database. Use flags for this. This is another layer of testing and you need to be sure about the correct setup of each test.

Only integration tests does b