Testing Blog

TotT: Using Dependancy Injection to Avoid Singletons

Thursday, May 15, 2008
Share on Twitter Share on Facebook
Google
Labels: TotT

12 comments :

  1. Calvin SpealmanMay 18, 2008 at 3:34:00 PM PDT

    This doesn't cover a few downfalls to the approach.

    It requires the users of the client know about where to get the singleton and it forces them to access it for every creation of the client class.

    Another problem is that the singleton that this ignores the difference in when the singleton is acquired, which could have important implications that need to be addressed.

    It should be included in such a suggestion that the client class take the singleton injection as an optional parameter, and access the singleton by default, possibly and specifically on each use of the singleton.

    ReplyDelete
    Replies
      Reply
  2. Ran BironMay 19, 2008 at 11:07:00 AM PDT

    After several failures, we (I and my team in the undisclosed company I work for) got to couple of conclusions:
    1. DI frameworks (e.g. Spring) are extremely friendly for testing.
    2. If you can't use a DI framework, create (a simple) one.
    Now (2) requires some explanation – what we do is have one real singleton – The singleton (application context, container, god – take your pick) which acts as a very restricted access map to several contexts "hubs". Each hubs converse directly with the map, first loading it with the required objects, then extracting and typecasting as needed. Context objects have a very small footprint on construction and are only initialized on event (application init) / request (same as real singletons)
    Testing is facilitated in either of two ways:
    1. If you only need a small number of mock contexts, you create them and load them manually into the singleton map. Future requests will retrieve them. On tests teardown, you empty the entire map.
    2. If you need a large number of mock contexts (big unit tests / integration tests), you just fire one (or more) of the real hubs and overwrite only what's needed in the map (if anything is) with mock implementations.

    This approach has the merit of being very easy on production code and yet (almost) as testable as real DI.

    ReplyDelete
    Replies
      Reply
  3. haemiMay 19, 2008 at 11:03:00 PM PDT

    To be honest, I do not see the advantage...

    With the first implementation of the Client-Class, it would have been possible to do:

    Client c = new Client();
    client.process();

    That's all... what's the drawback here?

    ReplyDelete
    Replies
    1. Leo Gutierrez RDecember 25, 2016 at 4:02:00 PM PST

      Hmmm, the advantage is that with the second approach, we have extracted the Server creation which will allow us to mock it. That wasn't possible with the first approach.

      Delete
      Replies
        Reply
    2. Reply
  4. JohnMay 20, 2008 at 9:43:00 AM PDT

    It's hard to test code that uses singletons. << understatement of the year :P
    We have had alot of luck using DI for testing, and when singletons are necessary provide an alternative getInstance method which takes in the parameters to construct the object with for testing.

    ReplyDelete
    Replies
      Reply
  5. DavidMay 20, 2008 at 3:31:00 PM PDT

    For this thing I use Guice.

    ReplyDelete
    Replies
      Reply
  6. Gauthier DelamarreJune 20, 2012 at 7:40:00 AM PDT

    years after... :) well, but PHPUnit official documentation is still linking to this blog post so...

    This post is a great and clear explanation of DI benefit at time of unit testing code, but in any case does it demonstrate what problems singletons are causing when unit testing code.

    As said haemi, the first Client.process() method implementation could (not should :)) have been done like this:

    public int process(Params params) {
    Server server = new Server();
    Data data = server.retrieveData(params);
    ...
    }

    In this case, we don't have any singleton involved, but we still cannot unit test this method because of a hard dependency on Server class.

    Indeed, the biggest issue with singleton is to unit test it's different methods independently, since you're not supposed to be able to reset the instance between method calls.

    Using introspection (or, but it's kind of ugly, implementing a resetInstance() public method to delete the current instance and allow instantiating a new one), you can manage to unit test a singleton's methods.

    Tu sum up, dependency injection and singletons are not related in any way!

    ReplyDelete
    Replies
      Reply
  7. roniOctober 3, 2014 at 2:26:00 AM PDT

    It's NOT hard to test code that uses singletons
    It's easy.

    This is how I test a client that uses a Singleton:
    First, I refactor the code that obtains the Singleton instance into a new protected method, as follows:

        public class Client {
           public int process(Params params) {
              Server server = obtainServer();
              Data data = server.retrieveData(params);
              ...
           }

           //new method
           protected Server obtainServer() {
              return Server.getInstance();
           }

        }

    Then I test it using a mock Server as follows:

        public class ClientTest extends Client {
           public void testProcess() {
              Client c = new Client() {
                 @Override protected Server obtainServer() {
                    return new MyMockServer();
                 }

              };
              assertEquals(5, c.process(params));
           }

    ReplyDelete
    Replies
    1. Tadeu Arias VillaresSeptember 25, 2016 at 7:56:00 AM PDT

      Sorry to ask this after so long, but can you explain/point a source about how to create your own mock client?

      Thanks!

      Delete
      Replies
        Reply
    2. Don GilliesJanuary 15, 2018 at 10:55:00 AM PST

      We used this sort of idea extensively on the Iridium Satellite payload project in the late 1990's. Every single interface had an include file with dependency inline functions, that so by swapping the includes you could mock *everything*. As a result, nobody could read anybody else's code because the language of each service was entirely different, and more or less, random.

      Delete
      Replies
        Reply
    3. Reply
  8. Jan BollackeNovember 19, 2014 at 2:29:00 AM PST

    Sure, but still ur API kind of s*cks. It is not clear hat Client has a strong dependency on Server - whether it is inside the public process() or protected obtainServer() method - unless it is properly documented. Dependency Injection shows off these dependencies right in the API. And you would have to create another subclass on every reuse of Client that needs a different logic to obtainServer(). Not to mention that - at least for me - it seems way out of scope for a client to obtain the server. Just my 2 cents.

    ReplyDelete
    Replies
      Reply
  9. Alexander TodorovNovember 4, 2015 at 3:03:00 PM PST

    Btw guys, you have a typo in the title of this page. See Dependancy vs Dependency.

    I was spell checking an article which includes a link to this page and this showed up.

    ReplyDelete
    Replies
      Reply
Add comment
Load more...

The comments you read and contribute here belong only to the person who posted them. We reserve the right to remove off-topic comments.

  

Labels


  • TotT 72
  • GTAC 61
  • James Whittaker 42
  • Misko Hevery 32
  • Anthony Vallone 27
  • Patrick Copeland 23
  • Jobs 17
  • C++ 11
  • Code Health 11
  • Andrew Trenk 9
  • Patrik Höglund 8
  • JavaScript 7
  • Allen Hutchison 6
  • Zhanyong Wan 6
  • Harry Robinson 5
  • Java 5
  • Julian Harty 5
  • Alberto Savoia 4
  • Ben Yu 4
  • Erik Kuefler 4
  • Philip Zembrod 4
  • Shyam Seshadri 4
  • Chrome 3
  • John Thomas 3
  • Lesley Katzen 3
  • Marc Kaplan 3
  • Markus Clermont 3
  • Sonal Shah 3
  • APIs 2
  • Abhishek Arya 2
  • Alek Icev 2
  • Android 2
  • April Fools 2
  • Chaitali Narla 2
  • Chris Lewis 2
  • Chrome OS 2
  • Diego Salas 2
  • Dillon Bly 2
  • Dori Reuveni 2
  • George Pirocanac 2
  • Jason Arbon 2
  • Jochen Wuttke 2
  • Kostya Serebryany 2
  • Marc Eaddy 2
  • Max Kanat-Alexander 2
  • Mobile 2
  • Oliver Chang 2
  • Simon Stewart 2
  • Tony Voellm 2
  • WebRTC 2
  • Yvette Nameth 2
  • Zuri Kemp 2
  • Aaron Jacobs 1
  • Adam Bender 1
  • Adam Porter 1
  • Alan Faulkner 1
  • Alan Myrvold 1
  • Alex Eagle 1
  • Antoine Picard 1
  • App Engine 1
  • Ari Shamash 1
  • Arif Sukoco 1
  • Benjamin Pick 1
  • Bob Nystrom 1
  • Bruce Leban 1
  • Christopher Semturs 1
  • Clay Murphy 1
  • Dan Shi 1
  • Dan Willemsen 1
  • Dave Chen 1
  • Dave Gladfelter 1
  • Derek Snyder 1
  • Diego Cavalcanti 1
  • Dmitry Vyukov 1
  • Eduardo Bravo Ortiz 1
  • Ekaterina Kamenskaya 1
  • Elliott Karpilovsky 1
  • Espresso 1
  • Google+ 1
  • Goranka Bjedov 1
  • Hank Duan 1
  • Havard Rast Blok 1
  • Hongfei Ding 1
  • Jason Elbaum 1
  • Jason Huggins 1
  • Jay Han 1
  • Jeff Listfield 1
  • Jessica Tomechak 1
  • Jim Reardon 1
  • Joe Allan Muharsky 1
  • Joel Hynoski 1
  • John Micco 1
  • John Penix 1
  • Jonathan Rockway 1
  • Jonathan Velasquez 1
  • Josh Armour 1
  • Julie Ralph 1
  • Karin Lundberg 1
  • Kaue Silveira 1
  • Kevin Bourrillion 1
  • Kevin Graney 1
  • Kirkland 1
  • Kurt Alfred Kluever 1
  • Manjusha Parvathaneni 1
  • Marek Kiszkis 1
  • Mark Ivey 1
  • Mark Striebeck 1
  • Marko Ivanković 1
  • Matt Lowrie 1
  • Meredith Whittaker 1
  • Michael Bachman 1
  • Michael Klepikov 1
  • Mike Aizatsky 1
  • Mike Wacker 1
  • Mona El Mahdy 1
  • Noel Yap 1
  • Patricia Legaspi 1
  • Peter Arrenbrecht 1
  • Peter Spragins 1
  • Phil Rollet 1
  • Pooja Gupta 1
  • Project Showcase 1
  • Radoslav Vasilev 1
  • Rajat Dewan 1
  • Rajat Jain 1
  • Rich Martin 1
  • Richard Bustamante 1
  • Roshan Sembacuttiaratchy 1
  • Ruslan Khamitov 1
  • Sean Jordan 1
  • Sharon Zhou 1
  • Siddartha Janga 1
  • Simran Basi 1
  • Stephen Ng 1
  • Tejas Shah 1
  • Test Analytics 1
  • Tom O'Neill 1
  • Vojta Jína 1
  • iOS 1


Archive


  • ►  2019 (4)
    • ►  Dec (1)
    • ►  Nov (1)
    • ►  Jul (1)
    • ►  Jan (1)
  • ►  2018 (7)
    • ►  Nov (1)
    • ►  Sep (1)
    • ►  Jul (1)
    • ►  Jun (2)
    • ►  May (1)
    • ►  Feb (1)
  • ►  2017 (17)
    • ►  Dec (1)
    • ►  Nov (1)
    • ►  Oct (1)
    • ►  Sep (1)
    • ►  Aug (1)
    • ►  Jul (2)
    • ►  Jun (2)
    • ►  May (3)
    • ►  Apr (2)
    • ►  Feb (1)
    • ►  Jan (2)
  • ►  2016 (15)
    • ►  Dec (1)
    • ►  Nov (2)
    • ►  Oct (1)
    • ►  Sep (2)
    • ►  Aug (1)
    • ►  Jun (2)
    • ►  May (3)
    • ►  Apr (1)
    • ►  Mar (1)
    • ►  Feb (1)
  • ►  2015 (14)
    • ►  Dec (1)
    • ►  Nov (1)
    • ►  Oct (2)
    • ►  Aug (1)
    • ►  Jun (1)
    • ►  May (2)
    • ►  Apr (2)
    • ►  Mar (1)
    • ►  Feb (1)
    • ►  Jan (2)
  • ►  2014 (24)
    • ►  Dec (2)
    • ►  Nov (1)
    • ►  Oct (2)
    • ►  Sep (2)
    • ►  Aug (2)
    • ►  Jul (3)
    • ►  Jun (3)
    • ►  May (2)
    • ►  Apr (2)
    • ►  Mar (2)
    • ►  Feb (1)
    • ►  Jan (2)
  • ►  2013 (16)
    • ►  Dec (1)
    • ►  Nov (1)
    • ►  Oct (1)
    • ►  Aug (2)
    • ►  Jul (1)
    • ►  Jun (2)
    • ►  May (2)
    • ►  Apr (2)
    • ►  Mar (2)
    • ►  Jan (2)
  • ►  2012 (11)
    • ►  Dec (1)
    • ►  Nov (2)
    • ►  Oct (3)
    • ►  Sep (1)
    • ►  Aug (4)
  • ►  2011 (39)
    • ►  Nov (2)
    • ►  Oct (5)
    • ►  Sep (2)
    • ►  Aug (4)
    • ►  Jul (2)
    • ►  Jun (5)
    • ►  May (4)
    • ►  Apr (3)
    • ►  Mar (4)
    • ►  Feb (5)
    • ►  Jan (3)
  • ►  2010 (37)
    • ►  Dec (3)
    • ►  Nov (3)
    • ►  Oct (4)
    • ►  Sep (8)
    • ►  Aug (3)
    • ►  Jul (3)
    • ►  Jun (2)
    • ►  May (2)
    • ►  Apr (3)
    • ►  Mar (3)
    • ►  Feb (2)
    • ►  Jan (1)
  • ►  2009 (54)
    • ►  Dec (3)
    • ►  Nov (2)
    • ►  Oct (3)
    • ►  Sep (5)
    • ►  Aug (4)
    • ►  Jul (15)
    • ►  Jun (8)
    • ►  May (3)
    • ►  Apr (2)
    • ►  Feb (5)
    • ►  Jan (4)
  • ▼  2008 (75)
    • ►  Dec (6)
    • ►  Nov (8)
    • ►  Oct (9)
    • ►  Sep (8)
    • ►  Aug (9)
    • ►  Jul (9)
    • ►  Jun (6)
    • ▼  May (6)
      • Performance Testing of Distributed File Systems at...
      • TotT: The Invisible Branch
      • Intro to Ad Quality Test Challenges
      • Exploratory Testing on Chat
      • TotT: Using Dependancy Injection to Avoid Singleto...
      • TotT: Testable Contracts Make Exceptional Neighbor...
    • ►  Apr (4)
    • ►  Mar (4)
    • ►  Feb (4)
    • ►  Jan (2)
  • ►  2007 (41)
    • ►  Oct (6)
    • ►  Sep (5)
    • ►  Aug (3)
    • ►  Jul (2)
    • ►  Jun (2)
    • ►  May (2)
    • ►  Apr (7)
    • ►  Mar (5)
    • ►  Feb (5)
    • ►  Jan (4)

Feed

Subscribe by Email

follow us in feedly

Company-wide

  • Official Google Blog
  • Public Policy Blog
  • Student Blog

Products

  • Google for Work Blog
  • Chrome Blog
  • Official Android Blog

Developers

  • Ads Developer Blog
  • Android Developers Blog
  • Developers Blog
  • Google
  • Privacy
  • Terms