firefox-devtools / debugger

The faster and smarter Debugger for Firefox DevTools 🔥🦊🛠
https://firefox-dev.tools/
4.61k stars 759 forks source link

Convert cypress tests to mochitest #612

Closed jlongster closed 8 years ago

jlongster commented 8 years ago

Jason, it'd be great you focused on mochitests for the next few days. Now that mochitests run fine in #576, we can definitely use them for tests. I don't think we should be writing any more cypress tests right now and should just be using mochitests for the time being. We should flesh out the mochitest setup you started with the simple mochitests and start writing more complicated ones (just convert the cypress ones over).

We should really focus on testing now and avoid landing much new code. We're not even close to having good tests and we can't think about turning the new debugger on until we have a lot more unit tests and mochitests (you mentioned this in the last meeting, and we should focus on it this week!)

jasonLaster commented 8 years ago

We should really focus on testing now and avoid landing much new code

Completely agree. I'm going to work on

I don't want to spend the week switching to mochitest entirely as I'd rather focus on getting the right tests in to improve our coverage holistically.

mochitests

Last friday, I started working on writing more mochitests. It's important to me that we can have a good workflow around writing and debugging the new tests. I'm going to see what I can do here that will let us run the mochitests in the standalone mode and still debug the app.

jlongster commented 8 years ago

Last friday, I started working on writing more mochitests. It's important to me that we can have a good workflow around writing and debugging the new tests. I'm going to see what I can do here that will let us run the mochitests in the standalone mode and still debug the app.

Mochitests already have a good workflow; we've been using them for years... I'd rather not spend time trying to reinvent mochitest right now. You can debug them by just passing --jsdebugger. We really need to just convert cypress tests to mochitests :) At this rate we are not going to be able to land the debugger, I fear.

jasonLaster commented 8 years ago

I've been working on setting up a head.js that can drive our debuggee today and wanted to report back some of the work as a progress update:

Here is a small test that selects a source and some breakpoints

window.fun = function() {
  (async function () {
    await selectSource("todo-view");
    await addBreakpoint(33);
    await addBreakpoint(35);
  })();
};

and here are the commands it uses

function setupCommands(opts) {
  actions = opts.actions;
  store = opts.store;
  selectors = mapValues(opts.selectors, (selector) => {
    return function() {
      return selector(store.getState(), ...arguments);
    };
  });
}

function selectSource(url) {
  const source = selectors.getSources()
                .find(s => s.get("url").includes(url));

  actions.selectSource(source.get("id"));
  return wait(100);
}

function addBreakpoint(line) {
  const source = selectors.getSelectedSource();
  return actions.addBreakpoint({
    sourceId: source.get("id"),
    line
  }, {
    getTextForLine: l => window.cm.getLine(l - 1).trim()
  });
}

function debugTab() {
  const tabs = selectors.getTabs();
  const id = tabs.find(t => t.get("browser") == "firefox").get("id");
  window.location = `/?firefox-tab=${id}`;
}

function wait(time) {
  return new Promise(function(resolve, reject) {
    setTimeout(resolve, time);
  });
}

Once we have the helpers setup we can easily use them in a mochitest.

jlongster commented 8 years ago

@jasonLaster A good start! I'd prefer to use the addBreakpoint action directly, and explicitly pass in the source. It common to set it on the selected source, but many tests also set multiple breakpoints on various sources. It's nicer to have a single API instead of a succinct one. I'd rather be more explicit: just use the actions directly! actions.addBreakpoint(...) You don't need getTextForLine unless you are explicitly testing the breakpoints panel.

setupCommands seems left over from cypress, and initDebugger still seems more appropriate, especially since for mochitests it's going to open the panel and everything.