1

I am new to adopting a completely TDD approach using DI so that I can mock every dependency. One of the pain points that I identified so far is the fact that whenever I do work in my constructor every test has to prepare for that sequence (expect the corresponding mock calls). An example for such a sequence might be creating sending a message or checking if a folder exists, etc.

Are there any best practices how to handle such situations. Right I consider the two options:

  1. No work in the constructor (cumbersome since I need to manually need to make sure the object's invariants are satisifed)
  2. Test the boot sequence individually and only work with intialized objects in the test afterwards

I could not really find insights on google how those problems are handled in general. Am I following a poor design principle?

Edit, Example added:

struct CachedObservable {
    INJECT(CachedObserable(
        std::shared_ptr<IO> io,
        std::shared_ptr<Observable> base
    ))
    {
         load_and_emit_cached_file_from_hdd_if_available(io);
         base->subscribe([this](auto& x) {
             save_value_in_file(cached_filepath);
             emit(x);
         });
    }

    void load_and_emit_cached_file_from_hdd_if_available(
         std::shared_ptr<IO> io
    )
    {
         if (io->file_exists(cached_filepath))
             emit(io->load(cached_filepath));
    }
    ...
};

The example is an abstraction but captures the real use-case. I use fruit & rxcpp to have a replay subject that does two things:

  1. On construction load a cached value from a file on the hdd and emit the content
  2. Forward all values emitted from the injected observable and cache the latest object

I use mocks for both io and observable to completely isolate the behavior of the class

Improve this question
4
  • 2
    An example would make your question much clearer. Commented Oct 2, 2017 at 7:33
  • As @DocBrown mentions an example is needed to be sure, but if you are having to keep testing different combinations of multiple variants in combination with seemingly independent test cases, it's very likely you have an abstraction problem. Commented Oct 2, 2017 at 13:02
  • @DocBrown thank you for the suggestion, I have added an example. In my opinion the level ob abstraction is fine, the object does not too a very limited and specific amount of things. It's just that the nature of it (loading cached values on init) requires work in the constructor. But I am happy and open about any kind of suggestions Commented Oct 2, 2017 at 21:45
  • This would only affect your tests for CachedObservable, right? In which case, the "boot up sequence" is actually relevant to the tests? Commented Apr 15, 2019 at 23:28

2 Answers 2

Reset to default
4

No work in the constructor (cumbersome since I need to manually need to make sure the object's invariants are satisifed)

No work in the constructor is a really good idea. Flaw: Constructor does Real Work, by Miško Hevery, covers this ground pretty well. He wrote a number of posts on testability. The main technique is often called dependency injection; an objects collaborators are passed to the constructor, rather than created by the constructor.

Enforcing the object's invariant invariant is still handles by the constructor; the constructor logic checks that the required collaborators are not null, that the values are restricted to a valid range, and so on. It might also require checking that the collaborators are satisfactory - which would be done by verifying the collaborator using its own public interface.

This still means that any test that creates an object needs to provide a complete set of collaborators; when this is cumbersome, that may be a hint that your object has too many different responsibilities, and should be refactored.

Ultimately, however, any unit test that involves a lot of collaborators is going to require a fair amount of setup. There's no magic. You can sometimes elide a number of collaborators that aren't particularly interesting for a specific test by replacing a root collaborator with a test double, eliding the part of the dependency graph that would normally go there.

Improve this answer
1
  • I agree that the work in the constructor should be limited. However in my example (see above) I am dealing with a Caching decorator that is reading a file on construction and emitting it in an observable. I cannot see an elegant way to defer the execution without having a ugly init function. Any suggestion how to tackle that? Commented Oct 2, 2017 at 21:38
3

It is common to have to perform operations prior to your testing, and it isn't really practical to write tests which test everything being run within any given test. The typical approach here is to write an explicit test, say test A, to verify that the setup is done properly, and treat that as its own test. Then any test that requires that same setup, test B, simply assumes the setup is done properly.

The idea is that if you run all tests, while perhaps your test B gives you a false positive due to working with the assumption that the setup was done properly, your test A fails, because it was testing precisely this.

The key here being that everything is subject to being tested, even if not necessarily in the test that requires it.

And no, do your best to avoid performing "risky" operations in your constructor. If necessary, perform a lazy load that initializes your instance first time it is used. Or treat it as a resource that must be open/closed and therefore should be called explicitly.

Improve this answer
1
  • Thank you for the suggestion. At the moment I am following the approach suggested by you. I work with an ExpectationSet (gmock) that are generated in a common function and that needs to be fulfilled for the tests relying on an initialized object. It feels unelegant though, since breaking one contract in the constructor breaks all the tests relying on an initialized object which seems to be against the idea of TDD and test isloation. Commented Oct 2, 2017 at 21:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.