Broken tests nesting incorrectly

16 views
Skip to first unread message

Michael Gaffney

unread,
Sep 16, 2009, 2:30:18 PM9/16/09
to jasmi...@googlegroups.com
I'm having an issue where when I have a test break, like say when I
create a class that doesn't exist, the rest of the tests don't nest
correctly, but I also don't get a failure.

For example:

descibe("DecryptHash", function(){
describe("a nested hash", function(){
var hash = {
key1: {
key2: "value"
}
};
var crypted = new EncryptHash(hash, password).hash;
// doesnt exist, should be DecryptHash
var decrypted = new DecryptHashed(crypted, password).hash;
it("should be the same", function(){
expect(decrypted.key1.key2).toEqual(hash.key1.key2);
});
});
});
//and in another file
describe("aes"){
describe("encoding", function(){
it("should be true", function(){
expect(true).toEqual(true);
});
});
});

And the first file is loaded before the second, then aes gets nested
inside of the DecryptedHash part. I'm not sure if the above example will
work or not. If it doesn't I can send my real project and show the issue.

-Mike

Rajan Agaskar

unread,
Sep 16, 2009, 2:57:35 PM9/16/09
to jasmi...@googlegroups.com
There's a couple problems here I can see

1) bad scope on the var hash (that assignment won't get outside the nested describe)
2) bad syntax on describe('aes') -- should be describe('aes', function () {} ....). this will probably cause problems -- unfortunately, we don't yet do any syntax checking on suites before setting jasmine loose (it's on the roadmap), so this is probably why you are seeing weirdness.

Also, I would suggest that your var assignments happen either in a beforeEach or an it scope, I.E., instead of

describe("a nested hash", function(){
        var hash = {
            key1: {
                key2: "value"
            }
        };
        var crypted = new EncryptHash(hash, password).hash;
       // doesnt exist, should be DecryptHash
        var decrypted = new DecryptHashed(crypted, password).hash;
        it("should be the same", function(){
            expect(decrypted.key1.key2).
toEqual(hash.key1.key2);
        });
    });

You should do something like

describe("a nested hash", function(){
  var hash, crypted, descrypted;

  beforeEach(function() {

   var hash = { key1: {
     key2: "value"
   }
  };
  var crypted = new EncryptHash(hash, password).hash;
  // doesnt exist, should be DecryptHash
  var decrypted = new DecryptHashed(crypted, password).hash;
  });

Rajan Agaskar

unread,
Sep 16, 2009, 3:01:48 PM9/16/09
to jasmi...@googlegroups.com
Er, and the reason behind doing your assignments in a beforeEach or an it scope is that they are re-initialized for each test -- otherwise you run the risk of accidentally altering your assignment in such a way that it causes a subsequent test to fail. IE

describe('assignment confusion with foo', function () {
  var foo = 0;
  it('should equal 0', function () {
    expect(foo).toEqual(0); //passes
    foo = 1;
  });

  it('should still equal 0', function () {
    expect(foo).toEqual(0); //fails
  });
});

Although this is failing correctly, it's extremely confusing to be dealing with a variable that can change it's "starting" value between tests.

Michael Gaffney

unread,
Sep 16, 2009, 3:30:38 PM9/16/09
to jasmi...@googlegroups.com
Rajan,
This was just a example that I didn't run. #1 works, it's just ugly. #2
is coded like you say. I am just trying to avoid sending you 30 files to
illustrate the full issue. But I can if you want.

-Mike

Rajan Agaskar

unread,
Sep 16, 2009, 4:18:17 PM9/16/09
to jasmi...@googlegroups.com
I see. In theory we should be catching exceptions that occur in blocks (ie, beforeEach, it, runs, etc) and handling them appropriately (ie, marking the test as failed). If I recall correctly, any errors that occur inside of a describe block (which is evaluated before jasmine starts running tests) could cause strange behavior. If your example matches your actual test in this way, I could see it breaking. Maybe this means we should catch exceptions that occur in describe blocks.

I'll write up a test for this next time I get a chance and see what we can do about it.

Michael Gaffney

unread,
Sep 16, 2009, 4:33:24 PM9/16/09
to jasmi...@googlegroups.com
That sounds a likely culprit. Lemme try that.

Thanks,
-gaffo

Michael Gaffney

unread,
Sep 16, 2009, 4:37:02 PM9/16/09
to jasmi...@googlegroups.com
Yes, that was it. Tested it with and without. Works with a beforeEach
and breaks as described without. Many of my tests just had one it so I
didn't want to do a beforeEach on them.

Thanks,
Mike
Reply all
Reply to author
Forward
0 new messages