4 ms·

Doing x=C.get(x) is bad because there's no way of mocking C, thereby making unit testing a component that uses C impossible (the unit test will need to use the

• rdw 13y ago
  I realized recently that the reason that there is no way of mocking C is because of a weakness in the language implementation/design. In Python, it's easy to mock and unit test globals, because in the test you can just overwrite them in the test's setup, and restore them in the test's teardown. You could argue that it's a static vs dynamic typing thing, and I don't know enough to really dispute that, but it seems to me that there's no inherent reason that a static type system can't handle using a different concrete implementation. I think you can do this with Java/C# by doing some library loading trickery, but it'd be inconvenient. And that's the whole point of all this, isn't it? Automated testing is a convenience that saves you from doing manual testing. Unit testing is a convenience that catches test failures before commit rather than during the automated testing phase. Creating the unit test, well, is it more convenient to create 8 interfaces and completely change the way the code is structured, or is it more convenient to mock out the singleton? It depends on the circumstance, I've done both in various languages. It's good to have the option.
  • dllthomas 13y ago
    It's a scoping thing that has no direct relation to static/dynamic typing, though probably has plenty relation through the underlying philosophies of many lanaguages which motivate them to choose particular typing and scoping rules.
• shitgoose 13y ago
  Who says that you have to be able to mock C? Not every class should be mockable. In case described by OP, why would we want to mock cache anyways? In most cases singleton is used as a global state that can be easily accessed from all parts of the app without explicitly passing the state obj. We are dismissing a useful technique (singleton) based on requirement, that is not applicable to this technique.
  • Sandman 13y ago
    > Who says that you have to be able to mock C? Not every class should be mockable. In case described by OP, why would we want to mock cache anyways? Well it isn't really a unit test if you don't, is it? If you don't mock it then you're not only testing classes under unit tests, but also C's methods. And you're doing that not just in one place but in several different places in your testbase. The same methods. Over and over again.
    • shitgoose 13y ago
      I don't understand. If my unit test calls C.getX() over and over again, how is it bad?
      • l0u 13y ago
        In my case a cache could be something remote, having any calls directly to that will slow down unit tests a lot, having one or two calls to it unit testing the cache implementation it self is OK, but having every method which makes use of it make those calls isn't going to work. In reply to your original question, its not extremely bad if you can't unit test that class alone , but in this case you wouldn't be able to unit test anything which uses it either.
      • Sandman 13y ago
        C.getX() is going to be called by many different methods in many classes. This means that each time you unit test any of these methods, you're also testing C.getX() when you should only be testing what the method does.
• MortenK 13y ago
  I might be speaking blasphemy here, but is the advantages of unit testing worth the increased code complexity? In quite a few codebases I've seen, the amount of tests was entirely unrelated to how stable and maintainable the system was. Some times developers just fixed the tests, rather than the bugs. And in many cases, there were a slew of failing tests even though the system ran fine.
• dllthomas 13y ago
  Strictly, you could mock C by providing a static "replace the singleton" method, right? class SomeResource : public Singleton<SomeResource> { private: SomeResource *instance public: SomeResource &Instance() { if(!resource) makeResource(); return *resource; } void Mock(SomeResource *mock) { resource = mock } } class MockResource : SomeResource { ... }
  • Sandman 13y ago
    Sure, but: a) Now your singleton is also responsible for providing a mock implementation of itself (which shouldn't really be one of its concerns). b) You didn't really do anything here: the class under test is still going to use the concrete implementation of C. You need a way of providing a mock implementation to your class while testing. The obvious answer to how to do it is dependency injection. But if you're going down that route, you can just ditch the whole singleton thing, instantiate a class using "new" somewhere else and pass it to your class. And in your unit test, you simply pass the mock implementation. This is what DI containers like Spring do. We'd be doing the exact same thing here, only manually.
    • dllthomas 13y ago
      a) True, but it can probably be pushed into the parameterized Singleton class. I didn't try, since that might get more language dependent and since I wanted to keep things explicit-but-short for demonstration purposes anyway. b) You're touching a tiny part of the implementation of the real C, yes. If you're able to push the Instance and Mock functions into Singleton, you might be touching literally no code of C other than relying on the fact that it in-fact inherits from Singleton. I nonetheless agree dependency injection is a better solution. The biggest objection I have to this implementation is that there's nothing that tells me I should be mocking C, or catches it when I forget to mock C.
• l0u 13y ago
  Not only can you mock it for testing but it encapsulates the system better, there is no reason for straight access to C.get with this pattern you can easily drop in a brand new system for caching and not break your original code. Some might find that a bit too much like coding for the future, but in my case that is quite a likely situation to occur especially if you ever run into scaling issues.