title: Revealing Module Pattern - Unit Testing with Jasmine
body: <p>After a brief romance with the revealing module pattern I've come to realise a set-back when it comes to unit-testing modules. I cannot however decide if it is my approach to testing a module or whether there is some form of work-around.</p>
  
  <p>Consider the following code:</p>
  
  <pre><code>var myWonderfulModule = (function () {
    function publicMethodA (condition) {
      if(condition === 'b') {
        publicMethodB();
      }
    }
  
    function publicMethodB () {
      // ...
    }
  
    return {
      methodA : publicMethodA,
      methodB : publicMethodB
    }
  }());
  </code></pre>
  
  <p>If I wanted to test (using Jasmine) the various paths leading through publicMethodA to publicMethodB. I might write a small test like so:</p>
  
  <pre><code>it("should make a call to publicMethodB when condition is 'b'", function() {
    spyOn(myWonderfulModule , 'publicMethodB');
    myWonderfulModule.publicMethodA('b');
    expect(myWonderfulModule.publicMethodB).toHaveBeenCalled();
  });
  </code></pre>
  
  <p>If I understand correctly, there's a copy of publicMethodB within the closure that cannot be changed. Even if I change myWonderfulModule.publicMethodB afterwards:</p>
  
  <pre><code>myWonderfulModule.publicMethodB = undefined;
  </code></pre>
  
  <p>calling <code>myWonderfulModule.publicMethodA</code> will still run the original version of B.</p>
  
  <p>The example above is of course simplified but there are plenty of scenarios I can think of where it would be convenient to unit test conditional paths through a method. </p>
  
  <p>Is this a limitation of the revealing module pattern or simply a misuse of unit testing? If not what work-arounds are available to me? I'm considering moving to something like RequireJS or reverting back to non-modular code. </p>
  
  <p>Any advice appreciated!</p>