Fix "mochawd" to work without the control flow

[sjelin]

The equivalent of jasminewd for mocha is in lib/frameworks/mocha. It needs to support the control flow being turned off

[sjelin]

The core issue is that in #3781 we hard-code selenium-webdriver's implementation into Protractor. The reason why we do this is because we want to overwrite functions like global.it, but as of 3.0.0-beta-4 selenium-webdriver's wrapped it queries for global.it at invocation time. So by overwriting global.it withselenium-webdriver's wrapped version, we create a circular reference. We could do one of two things:

a) Fix/maintain the code we've brought over

b) Change our wrappers to restore the global function when selenium-webdriver queries for it

• Implementation 1

  // This doesn't work for functions than can be nested (e.g. `describe`),
  // but we don't currently wrap those anyway
  global.it = function() {
    var wrappedIt = global.it;
    global.it = mocha.it;
    seleniumMochaWrappedFns.it.apply(this, arguments);
    global.it = wrappedIt;
  }

• Implementation 2

  global.it = function() {
    if (stackTraceShowsSeleniumCalledUs()) {
      return mocha.it.apply(this, arguments);
    } else {
      seleniumMochaWrappedFns.it.apply(this, arguments);
    }
  }

• Implementation 3

  // Use counters to allow for nested calls
  // This implementation could cause problems if mocha queries for global functions
  // before this code is run (as they did in their old implementation), but that 
  // could be solved with slightly more complex code
  var unwrapCounters = {
    it: 0
  };
  global.it = function() {
    if (unwrapCounters.it > 0) {
      unwrapCounters.it--;
      return mocha.it.apply(this, arguments);
    } else {
      unwrapCounters.it++;
      seleniumMochaWrappedFns.it.apply(this, arguments);
    }
  }

I prefer option b, implementation 1. It's not too complex, should work for all the cases we support, and allows us to use selenium-webdriver's library instead of maintaining our own

[heathkit]

+1 for the first approach. Seems like the least maintenance burden, and if we don't currently wrap nested calls why add it?

[juliemr]

I'm down with approach 1 too.