Unit tests about aura HOT 38 CLOSED

I don't see any tests in master, is that correct?

from aura.

Correct. No tests yet. That's next up :-)
On Jun 8, 2012 1:51 PM, "Joel Hooks" <
[email protected]>
wrote:

I don't see any tests in master, is that correct?

---

Reply to this email directly or view it on GitHub:
https://github.com/addyosmani/backbone-aura/issues/22#issuecomment-6212778

from aura.

Do you have a plan for them? I'd enjoy writing some, but I'm wondering what the preference in regards to testing library, folder structure, etc might be before I dig in.

from aura.

@joelhooks We haven't really discussed it yet. I prefer QUnit simply because that's all I've ever used. I'm up for the latest and greatest if you have something else in mind.

Regarding structure: I'm always conflicted about where to put them and usually just end up throwing them in the main directory under a tests folder (and excluding them in the build).

It would be great to have your help! Thanks!

@addyosmani Do you have any preferences about the testing library or structure?

from aura.

@dustinboston I personally prefer Jasmine although QUnit isn't too much more difficult to use. Happy to opt for whatever you feel comfortable with!

from aura.

@addyosmani I like playing with new stuff, it's a go on Jasmine for me.

from aura.

I enjoy Jasmine and Sinon. I think either way anything I will write will be very small tests that should transport easily. The library syntax won't be a big deal if they need to change.

We can see about structure too, once tests are actually committed. Easy enough to alter.

Just wanted to make sure you guys weren't set on something in particular. Sounds like not, so let me see what I can get done.

from aura.

@joelhooks Let's do Jasmine, thanks!!

from aura.

In case it helps on test structure, here are some ideas:

• imo, we should be testing Aura itself (basic mediator, facade, permissions) first
• The extensions (in ext) and any demo specific tests should be tested outside of this

@dustinboston I guess this raises an interesting question. Aura on it's own could work without Backbone and it's really just the extensions that are being used to get this working with it. Should we be making it clearer that the Backbone part of the project and the demo are really just a demonstration of extension? I guess I've covered this in docs but maybe it could be better reflected in the file/directory structure.

e.g

aura
ext
--backbone
-- mediator, facade, permissions
demo
--anything related to the sample app
tests

from aura.

@addyosmani Yeah Aura could absolutely work on its own. The major caveat that I see right now is that it would be really confusing to use more than one set of ext files. It would be really badass if we were to add a way register extensions. Then one could drop them into a bunch of folders in the ext directory and just call the register method.

from aura.

@addyosmani @dustinboston Did you guys happen to see my little commit?

There will be some interesting challenges for testing some of these pieces. My approach in these situations is to add API as needed for testing, and then open it up for discussion afterwards in terms of "best" approach for the same result. With the mediator, for example, I need to be able to access the channels so I created an accessor function to facilitate that.

What might help move the ball down the field is if somebody that knew what the API was supposed to do stubbed out the describe/it blocks with simple failures in the it body. Not that the head scratching isn't interesting in its own right :>

from aura.

@joelhooks I saw it, I can start filling things in a bit (hopefully within the next three days, super busy week) once we get the changes merged.

from aura.

I went ahead and sent a pull request for the initial work I did. Should make it easy to just jump in and get started.

from aura.

@joelhooks Awesome, thank you!

from aura.

@joelhooks appreciate the unit tests. Just merged!

from aura.

I got the stubbed code in for the mediator but my internet connection is being stupid so I can't push the files yet. I'll let you know as soon as I do. In the meantime I have some thoughts:

1. @addyosmani how do you feel about throwing errors in the core? e.g. throw new Error("You're doing it wrong!"). I think it's a good idea but wanted to know how you felt about it.
2. @joelhooks how are you planning on testing the other modules? At work I currently have an HTML file for every module I'm testing but I can tell you it really sucks and is hard to maintain. I was thinking that just doing a bunch of require's like you have now (all on the same page) would work.
3. @addyosmani @joelhooks I think we need to stick with a common naming convention for files/functions/variables etc. Meaning the spec files would need to be lowercase and underscored. You all agree? idiomatic.js anyone? (I still haven't finished reading it all)
4. @addyosmani I think we need to solidify the core methods besides start, stop, etc. We should be writing tests for things like util and dom, etc. but I don't think we should start that until they're firm.

Thanks guys!

from aura.

@joelhooks Code is pushed. Have at it :-)

from aura.

Nice, just in time for the weekend. Some people like to golf, some
like to unit test. ;)

from aura.

@dustinboston I haven't thought ahead about the other modules. As DRY
as possible, but it might take a bit to see how to best approach it as
progress is made. I am also totally for standards like idiomatic.js. I
haven't read it thoroughly, but it looks good generally.

from aura.

@joelhooks lol at your previous comment. hahaha.

from aura.

1. I'm okay with us opting for throwing errors from core
2. Will let Joel answer
3. Agree we need a common naming convention. I agree with your suggestion.
   As for idiomatic, let's go for it - I already use it in a number of other
   projects.
4. What changes did you have in mind?

(Pardon the brevity of responses. Currently travelling)

On Friday, June 15, 2012, Dustin Boston <
[email protected]>
wrote:

I got the stubbed code in for the mediator but my internet connection is
being stupid so I can't push the files yet. I'll let you know as soon as I
do. In the meantime I have some thoughts:

1. @addyosmani how do you feel about throwing errors in the core? e.g.
   throw new Error("You're doing it wrong!"). I think it's a good idea but
   wanted to know how you felt about it.
2. @joelhooks how are you planning on testing the other modules? At work
   I currently have an HTML file for every module I'm testing but I can tell
   you it really sucks and is hard to maintain. I was thinking that just doing
   a bunch of require's like you have now (all on the same page) would work.
3. @addyosmani @joelhooks I think we need to stick with a common naming
   convention for files/functions/variables etc. Meaning the spec files would
   need to be lowercase and underscored. You all agree? idiomatic.js anyone?
   (I still haven't finished reading it all)
4. @addyosmani I think we need to solidify the core methods besides
   start, stop, etc. We should be writing tests for things like util and dom,
   etc. but I don't think we should start that until they're firm.

Thanks guys!

---

Reply to this email directly or view it on GitHub:
https://github.com/addyosmani/backbone-aura/issues/22#issuecomment-6349368

Addy Osmani

Developer Programs Engineer at Google
Blogger at: http://addyosmani.com
Phone: +44 7501 594 382

from aura.

idiomatic.js actually doesn't cover the naming of files, as far as I could see. The rest of it is very sane, imo.

from aura.

@joelhooks would you be interested in continuing to flesh out the testing side of things? I'm working on establishing what we should target with the first release at the moment and this would help a lot :)

from aura.

@addyosmani Yes. I will start adding some pomodoros this week and make some progress.

What I will do is go "fast and loose" where I have to, affecting change on objects and functions as needed. Generally this will mean adding extension points.

We can discuss "cleaner" approaches as progress is made.

On Jul 14, 2012, at 16:14, Addy Osmani [email protected] wrote:

@joelhooks would you be interested in continuing to flesh out the testing side of things? I'm working on establishing what we should target with the first release at the moment and this would help a lot :)

---

Reply to this email directly or view it on GitHub:
https://github.com/addyosmani/backbone-aura/issues/22#issuecomment-6986699

from aura.

@joelhooks Would you be interested in joining the team as a collaborator to help us get the project properly unit tested? I'd love to have a proper set of tests covered for the project launch :)

from aura.

@addyosmani Yes, I am very interested in getting this bad boy tested.
Adding me as a collaborator would expedite, for sure.

On Tue, Aug 7, 2012 at 6:22 PM, Addy Osmani [email protected]:

@joelhooks https://github.com/joelhooks Would you be interested in
joining the team as a collaborator to help us get the project properly unit
tested? I'd love to have a proper set of tests covered for the project
launch :)

—
Reply to this email directly or view it on GitHubhttps://github.com/addyosmani/backbone-aura/issues/22#issuecomment-7570298.

from aura.

@joelhooks Done! addyosmani/backbone-aura@387de0f

from aura.

I'm running into interesting issues testing RequireJS modules. Specifically, the mediator is using the the same instance for each test. This causes some subtle shared state problems and is generally a bad practice. I'm currently reviewing some existing solutions for this. Testr.js shows some promise.

It brings up a broader issue re: testing. I saw in another thread/issue there was some discussion of a rewrite. If we really want test coverage, it needs to be driving design decisions on some level. It is difficult to patch on solid useful tests as an afterthought.

from aura.

I agree that testing coverage should be a driving design decisions or at least be factored in. I'd be very interested to see how things work our with Testr.js. @joelhooks If you incur issues during your research that require design changes to our mediator implementation (e.g to better support multiple instances with non-shared state) I'd be happy for us to consider changing what we're doing for V1 to tackle this.

Moving forward, tests should definitely be included anytime we make fundamental design choices. I'm sure others have run into testing issues like this while using Aura so best we try nipping them in the butt sooner.

from aura.

I'm on the same page with @joelhooks. However, I haven't had chance yet to play with Testr.js, but from what I've seen so far it seems cool.

Moving forward, tests should definitely be included anytime we make fundamental design choices.

I agree with this statement because if we change Aura radically in V2 (single-file) testing will need to follow that fast-paced-stream-of-changes-pattern too.

from aura.

@joelhooks I think part of the problem is that we're trying to test the mediator through the backbone extension. It would be better to test each module separately (as much as possible). I've done this with good success at work.

I think we would be better served to (possibly) leave out testing of the extensions altogether, or at the very least test them separately. To me it's wasted time working on the demo rather than the core.

Thoughts? // cc @addyosmani, @robertd

from aura.

@dustinboston I totally agree. I set it up this way as the most "straight forward" way to bootstrap the mediator. The extension mediator has almost no functionality, but adds greatly to dependencies. It is really silly to be testing against window.core as the mediator instance under test.

Ultimately I'd rather be creating a new mediator instance (core, not extension) for each spec. My struggle is with the dependency overhead. Advice on taking a machete to that overhead would be a great help.

On Aug 13, 2012, at 21:57, Dustin Boston [email protected] wrote:

@joelhooks I think part of the problem is that we're trying to test the mediator through the backbone extension. It would be better to test each module separately (as much as possible). I've done this with good success at work.

I think we would be better served to (possibly) leave out testing of the extensions altogether, or at the very least test them separately. To me it's wasted time working on the demo rather than the core.

Thoughts? // cc @addyosmani, @robertd

—
Reply to this email directly or view it on GitHub.

from aura.

@joelhooks here's how I've done it:

TL;DR

Require the mediator spec in SpecRunner.html and have that file require the core mediator for testing.

The long version

Take a look at my CoffeeScript Design Patterns repo. The way it's set up will still work with Aura even though it's in CoffeeScript. There are a few differences:

• Instead of gathering all files into one module, you'd just require the core mediator
• You don't need to return a public API like I've done, because we already have one
• The spec runner code can stay as you have it. I'm using the non-pretty version

This approach gets rid of the global dependency and utilizes AMD for everything. For more information on why I set it up that way check this out: True universal JavaScript modules with write-once-run-anywhere Jasmine specs

from aura.

@joelhooks If you would like, we could close this issue in favor of several smaller more focused ones. Would that be of interest of would you feel more comfortable with us continuing the broader testing discussion on this thread?

from aura.

@addyosmani To late to suggest Mocha?

It has that beautiful nyancat reporter.

from aura.

I don't think its too late to suggest Mocha. I know converting over projects to use it generally isn't that hard but I'll defer to @joelhooks who is currently focusing on our tests when he has time. If he's comfortable with it, I don't mind :)

from aura.

Just to give some perspective of how easy it should be, here's the commit that converted the Ember.js+RequireJS in TodoMVC from Mocha to Jasmine.

Mocha has a better future, more frequently updated, more liked, faster and more configurable.

from aura.

Unit tests are being added as necessary for Aura 1.0 core and will be written for the demo application once we've written it up. Closing this for now.

from aura.