FLUID-5929: IoC tests exit with no results if jqUnit is not available...

Description

I am experiencing some very odd test failures in new tests. Basically the tests are queued but never run.

After much investigation, I discovered that most of my existing tests either require node-jqunit or call something that does that for them, like kettle.loadTestingSupport or gpii.express.loadTestingSupport.

Here is a simple example that should run on its own, but which does not:

/* eslint-env node */
"use strict";
var fluid = require("infusion");
fluid.loadTestingSupport();

require("node-jqunit"); // Comment this out and the tests will never run.

fluid.defaults("gpii.tests.wtf.caseHolder", {
    gradeNames: ["fluid.test.testCaseHolder"],
    modules: [{
        name: "Confirm that things are borderline sane...",
        tests: [
            {
                name: "We should be able to run a single test...",
                type: "test",
                sequence: [
                    {   func: "jqUnit.assert", args: ["Here we are now."] }
                ]
            }
        ]
    }]
});

fluid.defaults("gpii.tests.wtf.environment", {
    gradeNames: ["fluid.test.testEnvironment"],
    components: {
        caseHolder: {
            type: "gpii.tests.wtf.caseHolder"
        }
    }
});

fluid.test.runTests("gpii.tests.wtf.environment");

Although I have this problem in various projects with different versions, here are the versions of node-jqunit and infusion in one project that doesn't work:

"infusion": "2.0.0-dev.20160519T222603Z.754d2c6",
    "node-jqunit": "1.1.4",

The workaround for now is to require node-jqunit manually.

Comments

• Tony Atkins [RtF] commented 2016-07-20T04:50:49.526-0400

  Update, requiring jqUnit resolves this, which is why I don't usually see this. Usually I have at least one local test function. Lately I have been able to write more "pure" tests that only call existing functions from sequence steps. It is these that will not work on their own.

  Moving this issue to infusion, as it is not a problem with Kettle. Calling kettle.loadTestingSupport just solves the problem because somewhere along the way it requires jqUnit.

• Tony Atkins [RtF] commented 2016-07-20T05:03:09.344-0400

  On further investigation, I discovered that the problem is a result of jqUnit.assert not being available as a global variable (makes sense). I get the same failure if I change the example to use "bogus".

  Seems like all we need is something to throw a proper error if "func" doesn't exist.

• Tony Atkins [RtF] commented 2016-07-20T05:05:59.186-0400

  Sorry, I keep updating my example to confirm, it looks like even if you don't call a jqUnit function, jqUnit is required. The framework does correctly throw an error about a bogus function, but only if jqUnit has been required.

  Here's an updated example that clearly illustrates the problem:

  /* eslint-env node */
  "use strict";
  var fluid = require("infusion");
  fluid.loadTestingSupport();
  
  //require("node-jqunit");
  
  fluid.defaults("gpii.tests.wtf.caseHolder", {
      gradeNames: ["fluid.test.testCaseHolder"],
      modules: [{
          name: "Confirm that things are borderline sane...",
          tests: [
              {
                  name: "We should be able to run a single test...",
                  type: "test",
                  sequence: [
                      {   func: "console.log", args: ["Here we are now."] }
                  ]
              }
          ]
      }]
  });
  
  fluid.defaults("gpii.tests.wtf.environment", {
      gradeNames: ["fluid.test.testEnvironment"],
      components: {
          caseHolder: {
              type: "gpii.tests.wtf.caseHolder"
          }
      }
  });
  
  fluid.test.runTests("gpii.tests.wtf.environment");
  

• Antranig Basman commented 2016-07-20T07:17:56.195-0400

  Yes, this is a long-standing annoyance. I think it can really only be resolved sensibly by eliminating the annoying node-jqunit module and folding this into Infusion. However, this itself also relies on some kind of "monorepo" pattern for Infusion itself so that all these dependencies can be properly isolated within it.