http://jasmine.github.io/2.0/introduction.html

Hey guys,

any plan / date in the near future to support the 2.0 version?

Thanks for your work :)

jasmine-core is the official release from the Jasmine project for NodeJS. I'd suggest you get Jasmine 2.0 from there (the version that is released for Node)

Oh nice! Definitely check out jasmine-core. I hadn't seen that. Jasmine 2.0 support is a ton of work, so if jasmine-core fits your purposes...

Alright then, I'll give it a try!

Thanks :)

Hello. [email protected] doesn't seem ready for Node. To require it instead of require('jasmine-core'); one should use strange require('jasmine-core/lib/jasmine-core/jasmine');. However, I found no signs of it or describe in it. And also there is no exectuable to actually run tests (just like it done here in jasmine-node). Maybe I got something wrong.

How can someone use it? I would prefer 2.0 due to better async support (as far as I know).

@StreetStrider, that's because Jasmine typically provides a boot.js file (browser-side). Such a file apparently isn't provided yet in the node package, I assume new packages will be added that do that?

I created a boot.js-type file by adapting portion of their node_suite.js file, which is apparently used to test Jasmine using Jasmine.

See my gist here. Creating this with Rhino server (commonjs) in mind, so would be best for you to adapt as necessary for Node.js: https://gist.github.com/intel352/8900895

@intel352, thanks for heads up, I will adapt for Node. At least for now I know that this part of work is still on my shoulders.

@StreetStrider, if you get a solution working specific to Node.js, please update the Gist (or create a new gist) to show the changes necessary. Part of our team works in Node, and may start using Jasmine there as well, and I'm sure others want similar.

Starting to create package for node. Most of code suits well, but I've replaced output variable (I dunno what it is) by console.log. https://github.com/StreetStrider/jasmine-nodal Async tests look fine.

Ah, error in omission on my part, output is a global var that simply exists for appending output. console.log seems a good solution :-)

So.. to clarify: there's no support planned for 2.0 in this project and it should be considered just a legacy project with no plans to support the current code?

Or is this more of a "we'll get there, but not right now" sort of thing (as obviously the jasmine-core project is... less than practical in comparison)?

+1 for plans on jasmine 2.0

Started the 2.0 work today. There's a lot of issues. We'll see how it goes.

On Monday, March 3, 2014, Christoph Burgmer [email protected] wrote:

+1 for plans on jasmine 2.0

Reply to this email directly or view it on GitHubhttps://github.com/mhevery/jasmine-node/issues/282#issuecomment-36565399 .

The way the jasmine-core and the boot.js system works is a headache for sure. That's one reason why I want your module to support it - to make my life easier! ;) hehe

:) I've got it loaded and running the specs, the reporter needs some serious work though.

On Monday, March 3, 2014, abritinthebay [email protected] wrote:

The way the jasmine-core and the boot.js system works is a headache for sure. That's one reason why I want your module to support it - to make my life easier! ;) hehe

Reply to this email directly or view it on GitHubhttps://github.com/mhevery/jasmine-node/issues/282#issuecomment-36567695 .

Oh, that bad? I've only dealt with code coverage for reporters so it's minimal. Didn't think much had changed except how they were registered (events/callback names being different).

Yeah, unknown what is wrong, might just have registered it wrong. Will spend some more time on it tomorrow.

On Monday, March 3, 2014, abritinthebay [email protected] wrote:

Oh, that bad? I've only dealt with code coverage for reporters so it's minimal. Didn't think much had changed except how they were registered (events/callback names being different).

Reply to this email directly or view it on GitHubhttps://github.com/mhevery/jasmine-node/issues/282#issuecomment-36568049 .

I know blanket.js had it's 2.0 adapter use the wrong names ;) it happens.

As far as I know the API is the following:

  jasmineStarted,
  jasmineDone,
  suiteStarted,
  suiteDone,
  specStarted,
  specDone

It might make sense to publish a package just for the jasmine bootstrapping that works under node and with requirejs. Other projects like grunt-contrib-jasmine are fighting with the same issues. Or actually merge it back to Jasmine, they seem generally interested.

Yeah, I'll consider repackaging once it's working, but my first priority is just getting it working within the current framework.

On Monday, March 3, 2014, Christoph Burgmer [email protected] wrote:

It might make sense to publish a package just for the jasmine bootstrapping that works under node and with requirejs. Other projects like grunt-contrib-jasmine are fighting with the same issues. Or actually merge it back to Jasmine, they seem generally interested.

Reply to this email directly or view it on GitHubhttps://github.com/mhevery/jasmine-node/issues/282#issuecomment-36570705 .

Thanks guys for putting efforts into this :+1:

Wow, gonna' take a complete rewrite of the reporter. Errrvrything is different. Got it running specs though! That's progress.

That's certainly progress!

That's a start! ;)

Didn't realize it was so different

First rev is located here: https://github.com/mhevery/jasmine-node/tree/Jasmine2.0 can anyone check it out and find glaring bugs?

Second Rev now supporting --verbose is available. I'm done for the day.

This is turning into a full scale rewrite. Any feedback on the current iterations would be really helpful

Hi again. @tebriel, Today I've tried adaptation in branch, you've posted. What is the spec file here? I've tried to use binary on this branch on my file that contains describe and it statements, however I got: "0 Tests, 0 Failures, 0 Skipped". Should spec be prepared some special way, that I do not know? I've checked examples on master, nothing special in spec though.

Hey, just execute it with node lib/jasmine-node/cli.js <args here> <specFolder> Lemme know if that works for you.

On Friday, March 7, 2014, StreetStrider [email protected] wrote:

Hi again. @tebriel https://github.com/tebriel, Today I've tried adaptation in branch, you've posted. What is the spec file here? I've tried to use binary on this branch on my file that contains describe and it statements, however I got: "0 Tests, 0 Failures, 0 Skipped". Should spec be prepared some special way, that I do not know? I've checked examples on master, nothing special in spec though.

Reply to this email directly or view it on GitHubhttps://github.com/mhevery/jasmine-node/issues/282#issuecomment-37012791 .

That way seemes not working as well. Here I tried to put additional info:

↳ npm ls --depth=0 | grep jasmine-node
└── [email protected]

I have tests directory:

↳ ls -1 tests/                                                   
parser
Reader.test.js

↳ node ./node_modules/jasmine-node/lib/jasmine-node/cli.js tests/

Finished in 0.001 seconds
0 Tests, 0 Failures, 0 Skipped

↳ node ./node_modules/jasmine-node/lib/jasmine-node/cli.js tests/Reader.test.js 

Finished in 0 seconds
0 Tests, 0 Failures, 0 Skipped

Ahh, there's your problem, your spec is named Reader.test.js. First, this exposed a bug, thanks! Second, to match tests that aren't in the format .*[Ss]pec\.js$ you need to specify either --matchAll or -m ".*test.js" Examples in my testing:

• node lib/jasmine-node/cli.js --matchAll spec/Test.test.js
• node lib/jasmine-node/cli.js -m ".*test.js" spec/Test.test.js

Make sure you pull latest, 'cause neither will work without it. Also I'm considering adding messages to note that you didn't match specs. Gotta' figure that out.

@tebriel I'll give it a try as soon as I've got some spare time

@tebriel, yes, thanks, I've pulled latest and --matchAll did the work. I might think that something is in naming convention. Indeed, all examples have Spec postfix.

Now available through npm as a beta version, via:

npm install -g [email protected]

:+1:

@StreetStrider RE: Your silent failure of not matching any specs, if jasmine-node finds no specs, it will alert you to this fact now:

~/G/jasmine-node:[Jasmine2.0]✑  jasmine-node spec/Test.Test.js

No Specs Matching /.spec\.(js)$/i Found
Consider using --matchAll or --match REGEXP


Finished in 0 seconds
0 Tests, 0 Failures, 0 Skipped

@tebriel , ye, thank you. This is what you mean when say about bug.

beta 2 is out on NPM. I've had to do some patching in the jasmine2.0 source. That code wasn't quite ready for production, it seems. Some of the changes I've added are in Jasmine's upstream, but the .any() comparison is f00bar'd. I found a workaround though.

npm install -g [email protected]

I think this will be the last beta. If anyone can give me a :thumbsup: or a :thumbsdown: it'd be appreciated.

npm install -g [email protected]

@tebriel I've tried it out on some of my node.js projects. Here my feedback / questions:

• add new line at the end of the spec report
• what about --captureExceptions option?
• it looks like the stack trace is printing only the first error message although many specs are failing (this is before the "migration", so not sure if it's a real issue though)

...............................................F..............F.............F..
bar [===============================================================================] 2/2 (= 100%) done
.
........-FF..
bar [===============================================================================] 2/2 (= 100%) done
.
........-F......FF........FF......FFFFFFFF.FF..
bar [===============================================================================] 2/2 (= 100%) done
.
....
bar [===============================================================================] 2/2 (= 100%) done
.
........-F.FFF.............FFFFFFFFFFFFFFFFF......FFFF.F.FF..
bar [===============================================================================] 2/2 (= 100%) done
.
........-......-FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF......FFFFFFFFFFFFFFFFFFFFFF..
bar [===============================================================================] 2/2 (= 100%) done
.
........-FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF..FFFF............F.FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF..FFFF....

Failures:

  1) #update should send update request
    Message:
      TypeError: Cannot call method 'expect' of nullFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF.FFFF.FFFFF.FFFFFFFFFFFFFFFFFFFFFFFFF.FFFFFFF.Fnicola: $

• the --verbose output (on failures) is like repeating recursively previous output (with increasing indentation) in a way that doesn't make much sense (I suppose it has something to do with async testing)

# example
ProductSync Start
    should initialize - 0 ms
    should initialize with options - 0 ms
    should throw error if no credentials are given - 0 ms
    should throw error if no 'client_id' is defined - 0 ms
    should send update request - 8 ms #marked as error
    ProductSync Start
      should initialize - 0 ms
      should initialize with options - 1 ms
      should throw error if no credentials are given - 0 ms
      should throw error if no 'client_id' is defined - 1 ms
      should throw error if no 'client_secret' is defined - 0 ms
      should throw error if no 'project_key' is defined - 1 ms
    ProductSync Finish - 3 ms

    ProductSync.buildActions Start
      should build the action update - 3 ms
    ProductSync.buildActions Finish - 3 ms

    ProductSync.update Start
      should send update request - 1 ms
    ProductSync.update Finish - 1 ms

    Sync Start
      should initialize - 0 ms
      should initialize with options - 1 ms
      should throw error if no credentials are given - 1 ms
      should throw error if no 'client_id' is defined - 1 ms
      should throw error if no 'client_secret' is defined - 1 ms
      should throw error if no 'project_key' is defined - 1 ms
      should send update request - 10 ms #marked as error
      Sync Start
        should initialize - 0 ms
        should initialize with options - 1 ms
        should throw error if no credentials are given - 0 ms
        should throw error if no 'client_id' is defined - 1 ms
        should throw error if no 'client_secret' is defined - 1 ms
        should throw error if no 'project_key' is defined - 1 ms
      Sync Finish - 4 ms

# ...and so on (it gets worse)

• the stacktrace doesn't show the source file (with line number) where the error happened

What can you tell me about those issues? Thanks for working on that btw ;)

Thanks. I'll work on these tomorrow. Already home for the day and left the laptop at work because otherwise I wouldn't ever sleep. :) In my local branch I have added captureExceptions back. What's going on with that "bar" thing? I haven't seen that before.

On Monday, March 10, 2014, Nicola Molinari [email protected] wrote:

@tebriel https://github.com/tebriel I've tried it out on some of my node.js projects. Here my feedback / questions:

• add new line at the end of the spec report
• what about --captureExceptions option?
• it looks like the stack trace is printing only the first error message although many specs are failing (this is before the "migration", so not sure if it's a real issue though)

...............................................F..............F.............F.. bar [===============================================================================] 2/2 (= 100%) done . ........-FF.. bar [===============================================================================] 2/2 (= 100%) done . ........-F......FF........FF......FFFFFFFF.FF.. bar [===============================================================================] 2/2 (= 100%) done . .... bar [===============================================================================] 2/2 (= 100%) done . ........-F.FFF.............FFFFFFFFFFFFFFFFF......FFFF.F.FF.. bar [===============================================================================] 2/2 (= 100%) done . ........-......-FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF......FFFFFFFFFFFFFFFFFFFFFF.. bar [===============================================================================] 2/2 (= 100%) done . ........-FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF..FFFF............F.FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF..FFFF....

Failures:

1. #update should send update request Message: TypeError: Cannot call method 'expect' of nullFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF.FFFF.FFFFF.FFFFFFFFFFFFFFFFFFFFFFFFF.FFFFFFF.Fnicola: $

• the --verbose output (on failures) is like repeating recursively previous output (with increasing indentation) in a way that doesn't make much sense (I suppose it has something to do with async testing)

example

ProductSync Start should initialize - 0 ms should initialize with options - 0 ms should throw error if no credentials are given - 0 ms should throw error if no 'client_id' is defined - 0 ms should send update request - 8 ms #marked as error ProductSync Start should initialize - 0 ms should initialize with options - 1 ms should throw error if no credentials are given - 0 ms should throw error if no 'client_id' is defined - 1 ms should throw error if no 'client_secret' is defined - 0 ms should throw error if no 'project_key' is defined - 1 ms ProductSync Finish - 3 ms

ProductSync.buildActions Start
  should build the action update - 3 ms
ProductSync.buildActions Finish - 3 ms

ProductSync.update Start
  should send update request - 1 ms
ProductSync.update Finish - 1 ms

Sync Start
  should initialize - 0 ms
  should initialize with options - 1 ms
  should throw error if no credentials are given - 1 ms
  should throw error if no 'client_id' is defined - 1 ms
  should throw error if no 'client_secret' is defined - 1 ms
  should throw error if no 'project_key' is defined - 1 ms
  should send update request - 10 ms #marked as error
  Sync Start
    should initialize - 0 ms
    should initialize with options - 1 ms
    should throw error if no credentials are given - 0 ms
    should throw error if no 'client_id' is defined - 1 ms
    should throw error if no 'client_secret' is defined - 1 ms
    should throw error if no 'project_key' is defined - 1 ms
  Sync Finish - 4 ms

...and so on (it gets worse)

• the stacktrace doesn't show the source file (with line number) where the error happened

What can you tell me about those issues? Thanks for working on that btw ;)

Reply to this email directly or view it on GitHubhttps://github.com/mhevery/jasmine-node/issues/282#issuecomment-37238461 .

@emmenko Can you pull (haven't pushed to npm) from Jasmine2.0 and try that? Also can you distill your verbose spec into something that I can run and duplicate on my box? I can't seem to get that error, but I vaguely recall having it during the first go-round of the reporter.

Sure, I'll get back to you as soon as I've tried.

PS: the "bar" thing is just some output from my implementation, don't worry ;)

:thumbsup: Thanks. I figured it had to be something with your stuff, because I've re-written the entire project now, and I know I didn't code anything like that lol.

So I've pulled the branch and got something interesting:

• I get the stacktraces now
• normally I have 134 tests, 245 assertions but now I get

Finished in 44.425 seconds
Started 461 tests, but only had 463 complete
463 Tests, 241 Failures, 6 Skipped

• also I get 1187 stacktraces

I'll see if I can get something to work but for me it looks like something gets recursively executed (I use nested describe if this can help).

I'll send you the output file separately.

@tebriel there you go

https://dl.dropboxusercontent.com/u/99485108/jasmine-node2.0_output.txt

Hmm, thanks. I think I have some deeply nested specs, but that's weird. I'm glad I added in that started vs finished check. That might help debug too. So weird.

On Tuesday, March 11, 2014, Nicola Molinari [email protected] wrote:

@tebriel https://github.com/tebriel there you go

https://dl.dropboxusercontent.com/u/99485108/jasmine-node2.0_output.txt

Reply to this email directly or view it on GitHubhttps://github.com/mhevery/jasmine-node/issues/282#issuecomment-37348812 .

@tebriel some more feedback:

• I noticed that if I run the single spec files they succeed but if I run then together they won't
• the stacktrace when the spec fails doesn't match the actual spec, I'll give you an example

1) #initMatcher should reject if error
    Message:
      Expected '{"foo": "bar"}' to equal { foo : 'bar' }.

    Stacktrace:
      Error: Expected '{"foo": "bar"}' to equal { foo : 'bar' }.
    at /Users/nicola/dev/src/sphere-node-sync/test/updater/inventory-updater.spec.js:117:25
    at _fulfilled (/Users/nicola/dev/src/sphere-node-sync/node_modules/q/q.js:797:54)
    at self.promiseDispatch.done (/Users/nicola/dev/src/sphere-node-sync/node_modules/q/q.js:826:30)
    at Promise.promise.promiseDispatch (/Users/nicola/dev/src/sphere-node-sync/node_modules/q/q.js:759:13)

Now if I look at the inventory-updater.spec.js:117 line, the expectation is correct

expect(channel).toEqual({
  foo: 'bar'
});

but the spec mentioned is not #initMatcher should reject if error rather #ensureChannelByKey should create a channel if not found

@emmenko

1. I've added a --debug flag to the latest in the Jasmine2.0 branch, this will list out (currently) all the files I'm loading and in what order, so we can see if we're loading some file multiple times or something. I'm thinking that maybe this is related to the recursion problem...possibly...I really just don't know. If I could run your specs (assuming they're not some sort of private IP) I could get to the bottom much quicker.
2. Do you have some sort of unclosed, nested it or describe possibly? I'm looking at the reporter code and I can't imagine how we'd get the spec mis-matched to its description, here's the code (with added comments:

    # Print out failed specs
    printFailures: ->
        # If we didn't find any failures, bail
        return unless @counts.failures > 0
        # Title print
        @config.print "\n\nFailures:"
        # In case we want to later change the tab spacing
        indent = "  "
        # For labeling the Failure number 
        count = 0
        # @allSpecs is a hash of suiteId:[Array<spec>], iterate all suites so that fails are grouped by suite
        for suite, specs of @allSpecs
            # Iterate each of the specs in the suite that we saved
            for spec in specs
                # failedExpectations is a Jasmine Array of `expect` that did not pass
                for failure in spec.failedExpectations
                    # Increment our current Failure Number
                    count++
                    @config.print """
\n
#{indent}#{count}) #{spec.fullName}
#{indent}#{indent}Message:
#{indent}#{indent}#{indent}#{@stringWithColor(failure.message,@config.color.fail())}\n
                    """
                    # Unless they said "no stack trace" let's print one
                    unless @config.noStackTrace
                        stack = @config.stackFilter failure.stack
                        @config.print """
\n
#{indent}#{indent}Stacktrace:
#{indent}#{indent}#{indent}#{stack}\n
                        """
        return

Hi there,

It looks like the 2.0 branch doesn't support --forceexit yet. Any plans to include this in 2.0?

@tebriel I think it would be better if you actually have a look directly to my code (you may want to disable the integration specs or get you the credentials for a SPHERE.IO project - you can create a free account, so don't worry)

https://github.com/emmenko/sphere-node-sync/tree/jasmine-2.0

@gabehollombe Hmm, yes, I removed it because I couldn't find a circumstance where it was hanging and not exiting, I can add it back in if you can give me some details on how to re-create so I can test.

@emmenko HOLY Crap. I have spent the entire day debugging this. I finally know what the problem is. Here's an example (from your specs) where things go wrong.

  it 'should return \'304\' if there are no update actions', (done) ->
    spyOn(@sync._rest, 'POST')
    callMe = (e, r, b) ->
      expect(e).toBe null
      expect(r.statusCode).toBe 304
      expect(b).toBe null
      done()
    # Synchronous Call, calls `done`
    @sync.update(callMe)
    # There should be no more code executed in this spec, because we said we were done
    expect(@sync._rest.POST).not.toHaveBeenCalled()

Because I aggregate the errors and problems and report them as we go, suddenly things get double/triple reported as they come through because more expectations come through after the suite is already reported as done. I'm not really sure what the right way to mitigate this is. The web reporter that Pivotal wrote has the same exact problem, but it's less apparent because it's just updating <div>'s.

Mitigation

I can ignore reports for specs/suites that come in after the suite has already reported that it was done once. This has the problem of you think I'm running your expect statements after you called done(), but I'm not actually. This would result in an error stating that there's likely more specs after a done call, and I'll fail the suite. Hopefully this won't take too long to code. Wow this was a helluva issue to figure out.

Example

@emmenko It's pushed, can you try it out? I know this is gonna' be a lot of work. It also lists all the specs where I saw the misfires at the end now :P

I've also filed this bug with Pivotal, we'll see if they decide that that should be fixed. https://github.com/pivotal/jasmine/issues/549

@tebriel have you tried it against master or the jasmine-2.0 branch (of my repo)?

I'll give it another try anyway. Thanks for finding out the (possible) problems though!! :+1:

Here is the new output

https://dl.dropboxusercontent.com/u/99485108/jasmine-node2.0_output2.txt

Btw: how was it done in the jasmine 1.x? Was that problem introduced by jasmine 2 itself?

And is this also the reason why I'm getting all those weird stacktraces?

That's what I was getting when I ran from the pull of your master. Can you cherry pick a few and see if my assumptions are correct? Only tired it on one of yours from the sync section.

On Thursday, March 13, 2014, Nicola Molinari [email protected] wrote:

Here is the new output

https://dl.dropboxusercontent.com/u/99485108/jasmine-node2.0_output2.txt

Reply to this email directly or view it on GitHubhttps://github.com/mhevery/jasmine-node/issues/282#issuecomment-37597202 .

It was a completely different mechanic in Jasmine 1.3. They changed two things majorly. First they removed the runs and waitsFor Syntax and adopted a form of the done callback. They also [over]simplified the reporter protocol. I no longer know what suite a spec belongs to expect by looking at what the last suite I saw reporting "start" was and I only know if they're nested by knowing that I haven't seen a suite done but I just got another suite start.

Because they implemented the done function, I had to remove the jasmine-node done/timeout that was implemented for 1.3. They are no longer verifying that an it has returned before reporting that a spec is done after a function calls done. Ideally both conditions would have to be true before reporting completion. The timeout for a spec is something that is implemented as well in jasmine, you can set a global jasmine variable to change it.

This is why there's so much crazy logging, and if a spec reports done before it actually is done, I get multiple notices that jasmine is done, and I can't know which one to trust as I never know if more are coming in the future, especially because I've seen a spec and suite done for every spec and suite that has come in. Jasmine just reports extra dones after those post-done() expect statements execute and the function returns.

I have deep jasmine 2.0 knowledge and am going to fork has 2, implement this, if I can, and then do a PR, but that's likely major surgery, and painful to my brain :p

Edited for clarity and because I wrote it on my iPad

Wow, that's kind of crazy. Didn't think it was that complicated.

@tebriel just take your time on that, personally I'm really happy at the moment with the 1.x version (especially the done callback) and I have no rush to upgrade. Seeing how things turned out now I think it was good to have found out the problems, now let's see what we can do to solve them and wait for an answer from the jasmine folks.

Thanks anyway for your effort, really appreciate it :)

@emmenko Can you try with the latest? I think all that's really missing now is for you to use the new syntax for spies and such. Here's the output I get after wrapping that done function to prevent early quitting of the spec: https://gist.github.com/tebriel/c7caae32a194ec11cc34

@tebriel thanks, I'll give it a try.

PS: I think you are testing against master branch. Please use the jasmine-2.0 branch (which has the newest syntax)

Oh whoops. Yeah, I'll try that later.

On Friday, March 14, 2014, Nicola Molinari [email protected] wrote:

@tebriel https://github.com/tebriel thanks, I'll give it a try.

PS: I think you are using testing against master branch. Please use the jasmine-2.0 https://github.com/emmenko/sphere-node-sync/tree/jasmine-2.0branch (which has the newest syntax)

Reply to this email directly or view it on GitHubhttps://github.com/mhevery/jasmine-node/issues/282#issuecomment-37702226 .

@emmenko Is this more what you were expecting? https://gist.github.com/tebriel/c7caae32a194ec11cc34

Yes better, although I still have the feeling that something is wrong.

Here is an example

$ jasmine-node --verbose --captureExceptions test/updater/inventory-updater.spec.js

Jasmine Started with 35 Specs
  InventoryUpdater Start
    should initialize - 4 ms
    should initialize with options - 1 ms
    should throw error if no credentials are given - 0 ms
  InventoryUpdater Finish - 7 ms

  #createEntry Start
    should create simplest entry - 0 ms
    should create complex entry - 1 ms
  #createEntry Finish - 1 ms

  #ensureChannelByKey Start
    should return a promise - 6 ms
    should query for channel by key - 2 ms
    should reject if error - 1 ms
    should create a channel if not found - 1 ms
    should reject when error during channel creation - 0 ms
    should reject if there was a problem during channel creation - 1 ms
  #ensureChannelByKey Finish - 12 ms

  #allInventoryEntries Start
    should return a promise - 1 ms
    should query all entries - 1 ms
    should reject if status code is not 200 - 0 ms
    should reject if error - 1 ms
  #allInventoryEntries Finish - 3 ms

  #initMatcher Start
    should return a promise - 1 ms
    should reject if error - 37 ms
    should return existing entries - 0 ms
  #initMatcher Finish - 38 ms

  #match Start
    should return entry based on sku - 1 ms
    should return entry based on sku and channel - 0 ms
  #match Finish - 1 ms

  #update Start
    should return a promise - 0 ms
    should reject if error - 1 ms
    should reject if there was a problem during update - 0 ms
    should return message that entry was updated - 1 ms
    should return message that updated was not necessary - 0 ms
  #update Finish - 3 ms

  #create Start
    should return a promise - 1 ms
    should reject if error - 0 ms
    should reject if there was a problem during create - 1 ms
    should return message that entry was created - 0 ms
  #create Finish - 2 ms

  #createOrUpdate Start
    should return if there are no inventory entries - 1 ms
    should init progress bar and return a promise - 2 ms
    should push update promise if entry exists - 1 ms
    should push create promise if entry exists - 4 ms
    should return result after update/create requests - 0 ms
    should reject if error when update/create requests - 1 ms
  #createOrUpdate Finish - 9 ms



Failures:

  1) #initMatcher should reject if error
    Message:
      Expected '{"foo": "bar"}' to equal { foo : 'bar' }.


    Stacktrace:
      Error: Expected '{"foo": "bar"}' to equal { foo : 'bar' }.
    at /Users/nicola/dev/src/sphere-node-sync/test/updater/inventory-updater.spec.js:117:25
    at _fulfilled (/Users/nicola/dev/src/sphere-node-sync/node_modules/q/q.js:797:54)
    at self.promiseDispatch.done (/Users/nicola/dev/src/sphere-node-sync/node_modules/q/q.js:826:30)
    at Promise.promise.promiseDispatch (/Users/nicola/dev/src/sphere-node-sync/node_modules/q/q.js:759:13)


  2) #createOrUpdate should push create promise if entry exists
    Message:
      Expected undefined to equal [ { id : 'channel123', sku : 'foo' } ].


    Stacktrace:
      Error: Expected undefined to equal [ { id : 'channel123', sku : 'foo' } ].
    at /Users/nicola/dev/src/sphere-node-sync/test/updater/inventory-updater.spec.js:249:56
    at _fulfilled (/Users/nicola/dev/src/sphere-node-sync/node_modules/q/q.js:797:54)
    at self.promiseDispatch.done (/Users/nicola/dev/src/sphere-node-sync/node_modules/q/q.js:826:30)
    at Promise.promise.promiseDispatch (/Users/nicola/dev/src/sphere-node-sync/node_modules/q/q.js:759:13)


  3) #createOrUpdate should push create promise if entry exists
    Message:
      Expected undefined to equal [ { id : 'channel123', sku : 'foo' } ].


    Stacktrace:
      Error: Expected undefined to equal [ { id : 'channel123', sku : 'foo' } ].
    at /Users/nicola/dev/src/sphere-node-sync/test/updater/inventory-updater.spec.js:250:31
    at _fulfilled (/Users/nicola/dev/src/sphere-node-sync/node_modules/q/q.js:797:54)
    at self.promiseDispatch.done (/Users/nicola/dev/src/sphere-node-sync/node_modules/q/q.js:826:30)
    at Promise.promise.promiseDispatch (/Users/nicola/dev/src/sphere-node-sync/node_modules/q/q.js:759:13)


Finished in 0.077 seconds
35 Tests, 2 Failures, 1 Skipped

Now if I look at the lines of the errors (from the stacktrace) I see that the spec description doesn't match the real one.

# refers to "#ensureChannelByKey should create a channel if not found"
/Users/nicola/dev/src/sphere-node-sync/test/updater/inventory-updater.spec.js:117

# refers to "#initMatcher should return existing entries"
/Users/nicola/dev/src/sphere-node-sync/test/updater/inventory-updater.spec.js:249

Any idea what's wrong here?

PS: I see that the in jasmine 2.0 you can configure the timeout as jasmine.DEFAULT_TIMEOUT_INTERVAL but here you can do this with jasmine.getEnv().defaultTimeoutInterval. Which one is the correct?

@emmenko I can't reproduce your problem of misnamed items from the jasmine-2.0 branch, but I have a bunch of promise issues that you don't have, potentially because I merged HEAD from master into jasmine-2.0 because I did a bad job checking out the branch. I get the same failures you do in the above example, but they seem to correspond to the correct tests. Can you pull again and try it? I don't know how that's happening, because the spec names and failures come straight from jasmine, I'm not making them up/pulling them out of some set of memory.

Also, use the jasmine.DEFAULT_TIMEOUT_INTERVAL as that's the jasmine way to do it...I believe. Seems to work in my cursory test. Let me know if not.

Tried again (checked out your repo again) and got the same issue. Can you checkout my repo again, switch to the jasmine-2.0 branch and try again?

Somehow something doesn't feel right here anyway...

@emmenko Will try out your stuff again today. Just published beta4 which can be installed at npm install -g [email protected]

@emmenko This is the problem:

  it 'should return result after update/create requests', ->
    spyOn(@updater, 'match').and.returnValue(null)
    spyOn(@updater, 'returnResult')
    spyOn(@updater.rest, 'POST').and.callFake((path, payload, callback) -> callback(null, {statusCode: 201}, null))
    @updater.createOrUpdate([{id: 'channel123', sku: 'foo_A'}, {id: 'channel456', sku: 'foo_B'}], -> ).then (result)=>
      expect(@updater.returnResult).toHaveBeenCalledWith(true, 'New inventory entry created.', jasmine.any(Function))

You have a ton of tests that execute asynchronous code but don't tell jasmine that it needs to wait for that code to finish executing. Like here:

  it 'should reject if error', ->
    spyOn(@updater.rest, 'GET').and.callFake((path, callback) -> callback('foo', null, null))

    @updater.ensureChannelByKey(@updater.rest, 'bar').then (channel) ->
      expect(channel).not.toBeDefined()
    .fail (msg) ->
      expect(msg).toBe 'Error on getting channel: foo'

Let me know if this is an incorrect assumption and all of these things are actually synchronous (all of your promise-type code, callbacks, etc). But When stuff fails, whatever test was most recently in the stack is then reported to be the parent of the failing async spec.

:+1: The jasmine-node 2.0.0-beta4 release works nicely for me.

@tebriel thanks, I'll give it a try :)

PS: those specs that you posted are actually synchronous since I spy on the actual async call and return something immediately. When I test async code I always use the done callback

it 'should do something async', (done) ->
  someAsyncCall().then (result) -> done()
  .fail (error) -> done(error)

@emmenko Okay, cool, let me know how it goes

@bendiken Thanks, glad to hear some positive feedback!

Works perfectly for me in my DateJS testing too.

@abritinthebay awesome. I'm in the process of switching jobs. I'm aiming for releasing final the week of May 12th, but if I get some extra time between there, I'll release earlier. Just want to give the code one more solid review and make sure that I'm not missing something important.

@tebriel looks good, I've tested it in a couple of projects and there was no issue ;)

Only minor thing: I notice that when I run it via a grunt task the colors are lost...

shell:
  options:
    stdout: true
    stderr: true
    failOnError: true
  jasmine:
    command: './node_modules/.bin/jasmine-node --verbose --captureExceptions test'

grunt.registerTask 'test', ['build', 'shell:jasmine']

Many thanks anyway for the huge efforts!!

@tebriel Nevermind, I saw in the code (https://github.com/mhevery/jasmine-node/issues/306) that you can pass the option forceColor, although it's not documented in the README.

Also the help output is not correct (there is a color flag in the usage, which isn't valid)

$ ./node_modules/.bin/jasmine-node -h
USAGE: jasmine-node [--color|--noColor] [--verbose] [--coffee] directory

Yeah, I was looking for a better way than forceColor, I was hoping it would be just an internal option passed around, but I guess that Grunt sets the isTTY flag to false. I may take the logic to set no color to true if we're not in a tty out. Undecided at this point.

Sent from my iPhone

On Apr 27, 2014, at 4:07 AM, "Nicola Molinari" <[email protected]mailto:[email protected]> wrote:

@tebrielhttps://github.com/tebriel Nevermind, I saw in the code (#306https://github.com/mhevery/jasmine-node/issues/306) that you can pass the option forceColor, although it's not documented in the README.

Also the help output is not correct (there is a color flag in the usage, which isn't valid)

$ ./node_modules/.bin/jasmine-node -h USAGE: jasmine-node [--color|--noColor] [--verbose] [--coffee] directory

— Reply to this email directly or view it on GitHubhttps://github.com/mhevery/jasmine-node/issues/282#issuecomment-41490761.

Can we at least add the --color flag option back in so that we can force the color when used within grunt?

I forked this repo and updated it to use jasmine-core instead of embedding Jasmine as part of this package. So you should (in theory) be able to use any version of Jasmine you wish. Though it's possible some versions don't work (I've only tested Jasmine 2.2.1).

Here's the fork.

Let me know what you think. Does it suck? Then send me a pull request or make an issue. Thanks!

Well Jasmine post 2.0 works totally different so it'll only work for the 2.0 release (and any API compatible version... hopefully they won't change too much in the future).

But that's a nice idea.

@abritinthebay Correct. I'll update the README to reflect that.

Luckily there's no reason to use my fork if you use any version of Jasmine <= 2.0.0 because this repo exists! :smile:

But if you want to use versions past 2.0.0, I think my fork is the only way right now. Correct me if I'm wrong.

PS: this repo has a 2.0 branch, which is also published to npm in case you want to use it.

'2.0.0-beta1',
'2.0.0-beta2',
'2.0.0-beta3',
'2.0.0-beta4',
'2.0.0'