incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse <purplecabb...@gmail.com>
Subject [DISCUSS] A plea for sanity in tests
Date Tue, 14 Aug 2012 22:47:38 GMT
The Mobile Spec File tests in jasmine contains some 3500+ lines of JS code.

*Lengthy Tests:*

I am currently working through some File API failing tests ( there are 95
specs, defined in 12 describe sections )

It would extremely helpful if I did not have to run all the passing tests
before getting to the test I am working on.
To that end, I think in the future when we write tests, we should separate,
at a minimum, each 'describe' block into it's own file.  That way I could
just comment out the script include, and run the section my failing test
was in. ( I currently have the first couple thousand lines commented out,
or returning immediately )

*Code Quality:*

It is considered a best practice in JS to hoist the variable definition to
the top of the function, because JS has function level scope and not block
level.  However, if your variable definition includes a length
initialization, you are missing the benefit/point/clarity of this practice.

Here is an example of what I think we should avoid:

it("FT.8.3  file should return a File object", function() {
    var fileName = "fe.file",
        newFile,
        entryCallback = jasmine.createSpy().andCallFake(function(fileEntry)
{
            newFile = fileEntry;
            runs(function() {
                fileEntry.file(itFile, fail);
            });
            waitsFor(function() { return itFile.wasCalled; }, "itFile never
called", Tests.TEST_TIMEOUT);
            runs(function() {
                expect(itFile).toHaveBeenCalled();
                expect(fail).not.toHaveBeenCalled();
            });
        }),
        itFile = jasmine.createSpy().andCallFake(function(file) {
            expect(file).toBeDefined();
            expect(file instanceof File).toBe(true);
            // cleanup
            newFile.remove(null, fail);
        }),
        fail = createFail('FileEntry');
    // create a new file entry to kick off it
    runs(function() {
        root.getFile(fileName, {create:true}, entryCallback, fail);
    });
    waitsFor(function() { return entryCallback.wasCalled; }, "entryCallback
never called", Tests.TEST_TIMEOUT);
});

The above becomes very difficult for a 'person' to parse. Compared to :
(this is a simplistic example, some of the 'it' blocks are hundreds of
lines long. )

it("FT.8.3  file should return a File object", function() {
    var fileName = "fe.file",
        newFile,
        entryCallback,
        itFile,
        fail = createFail('FileEntry');
    entryCallback = jasmine.createSpy().andCallFake(function(fileEntry) {
        newFile = fileEntry;
        runs(function() {
            fileEntry.file(itFile, fail);
        });
        waitsFor(function() { return itFile.wasCalled; }, "itFile never
called", Tests.TEST_TIMEOUT);
        runs(function() {
            expect(itFile).toHaveBeenCalled();
            expect(fail).not.toHaveBeenCalled();
        });
    });
    itFile = jasmine.createSpy().andCallFake(function(file) {
        expect(file).toBeDefined();
        expect(file instanceof File).toBe(true);
        // cleanup
        newFile.remove(null, fail);
    });
    // create a new file entry to kick off it
    runs(function() {
        root.getFile(fileName, {create:true}, entryCallback, fail);
    });
    waitsFor(function() { return entryCallback.wasCalled; }, "entryCallback
never called", Tests.TEST_TIMEOUT);
});


Thoughts?

-- 
@purplecabbage
risingj.com

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message