Deprecate global variables, group assert methods

[Krinkle]

Many reasons:

• Easier to extend by third parties (e.g. to implement a strict assertTrue, lt (less then) or gtOrEq (greater than or equal to) - no clashing names with utility functions and callback stuff.
• Makes the API more mobile and environmental friendly (e.g. issue Deprecate module, rename to group #190)
• Easier to add support for in linting applications (only 1 global)

I propose something along the the lines of:

• QUnit.group
• QUnit.test
• QUnit.assert.equal
  • maybe ability shorten to this.equal inside a test() ?

[AaronAsAChimp]

+1 To this, using QUnit.test would make everything easier.

What about this for syntax?

// extend assertions
QUnit.assert.awesome = function (potentially_awesome, message) {
    this.ok(potentially_awesome.isAwesome(), message);
};

// QUnit.assert is passed in as the first parameter to the test
QUnit.test('An Awesome object can be awesome.', function (is) {
    var an_obj = new AnObject();

    is.ok(an_obj instanceof Awesome, 'Does it inherit from Awesome?');
    is.equal(an_obj.max, 11, 'Does it go up to 11?');
    is.awesome(an_obj, 'Is it awesome?');
});

[jzaefferer]

Issue #190 is one thing, but not really a reason for removing all globals except QUnit itself.

As for linting applications, maybe we can get jshint to add a assert option, including all CommonJS assert module methods. That could simplify things a lot.

this inside a test already refers to the testEnviroment option, which you can initialize in a module-setup callback. Not a well-known feature, but has been around for a few years.

As for new assertion methods, those should always use QUnit.push to get correct source lines.

[Krinkle]

@AaronAsAChimp interesting syntax example. Another thing that may be useful (and fits well in the object-oriented syntax), is the use of a freeform "not".

// Extend assertions:
QUnit.assert.cowType = function (cow, expected, message ) {
    QUnit.push(Cow.types[cow.getTypeId()] === expected, Cow.types[cow.getTypeId()], expected, message);
};
QUnit.assert.gt = function (actual, expectMin, message ) {
    QUnit.push(actual > expectMin, actual, '> ' + expectMin, message);
};

// QUnit.assert is passed in as the first parameter to the test
QUnit.test( "FooCow and BarCow defaults", function ( assert ) {
    var bar, foo;

    bar = new BarCow();
    foo = new FooCow();

    assert.strictEqual( foo.name, "", "A FooCow has no name" );
    assert.gt( bar.spots, 10, "A cow has varying number of spots, but should be no less than 10" );
    assert.not.equal( bar.name, "Jack", "A BarCow is not named Jack" );
    assert.cowType( foo, "awesome", "A FooCow must be awesome" );
    assert.not.cowType( bar, "awesome", "A BarCow must not be awesome" );
});

@jzaefferer Okay, let's not use the this then. How about the assert argument?

[jzaefferer]

At this point I'd rather not discuss specifics, as I'm not convinced this really needs to change. You've listed three reasons, of which I consider two invalid (custom assertions, module/group naming), as those can be addressed in other ways.

I like the simplicity of those fourteen global methods and would like to keep that.

[Krinkle]

I agree if it were only 14 globals it would be somewhat manageable (on the edge and imho not preferable, but doable - for a test framework that is). But due to the downside of using ok() for custom assertions (One looses file path/line number debugging, and the failure output will only contain "false", not the actual values e.g. ok( 4 < 6, "msg" )), it is very attractive to create custom assertions, and we encourage developers to do so (using QUnit.push).

But that means people are forced (unless not following QUnit's example) to create globals and risk clashing with the many global variables out there already. Browsers these days have (inherited) globals like alert, atob, blur, btoa, find, isFinite, isNAN, isPrototypeOf, hasOwnProperty, .. not to mention the globals introduced by whatever other scripts are part of the tested application.

Note that we can stay backwards compatible as long as we want (just like we do now, like extend( window, QUnit, QUnit.assert )).

[jzaefferer]

I don't see the problem with making custom assertions not global. Not all QUnit methods are global, the addons assertions in particular are all namespaced to QUnit.

[AaronAsAChimp]

It would be nice to have all of the assertions in one spot. Having some global and some namespaced could be confusing. It seems like methods like ok, equal, or group are more likely to be overridden accidentally than QUnit.

test('Is my object ok', function () {
    ok = new MyObject();

    ok(ok); // Uh Oh!
    // Granted as you type that, you
    // should realize something's wrong.
});

Versus:

QUnit.test('Is my object ok', function (assert) {
    ok = new MyObject();

    assert.ok(ok); // Yay!
});