testing framework

[shaunc]

@BryanCrotaz -- can we use ember-cli-mocha, or do you (and/or your developer) prefer qunit? I am going to go through and at least fix the default tests so that we have a passing build.

[BryanCrotaz]

We use qunit. What are the advantages of mocha?

[shaunc]

I don't mind qunit, but I like

• integration with chai assertion library, which also integrates with sinon, and has lots of plugins for easy testing of various types of results (dates, regexes, etc.)
• ease of grouping tests into suites/subsuites (etc)
• automatic handling of promises (wait for thenable returned to complete)

[BryanCrotaz]

never used it but sounds good - go for it and show me how it's done

[BryanCrotaz]

feels like each section in the readme should become a test suite and each sentence should be a subsuite

[shaunc]

excellent...

... hmm...

---

Defining the window...

To specify the window, use the height and width attributes. The rowHeight attribute specifies the (outer) height of rows in the body of the grid.

describe('defining the window', ()=>{
  describe('to specify the window size, use the height and width attributes', ()=>{
    it('should size window to be 400x400', ()=>{
      ...
    }

---

Something like that?

[BryanCrotaz]

Each test should test exactly one thing, so tests for height and width individually within a suite. Suite names look good and understandable.

Just thinking that the way the readme is turning out, it's becoming a spec

[shaunc]

I used to use cucumber and that was the idea there. Here you've just written the documentation assiduously :)

[shaunc]

test module organization: We can put one test for each section per module in each file. ember has a default organization that we might want to be separate from as this is a bit different paradigm. Should I use ... say ... tests/specifications/<section-name>-test.js ?

[shaunc]

or specs rather than specifications

[BryanCrotaz]

sounds good

[shaunc]

I do more development in nodejs server side, where I use mocha all the time. Coming back to mocha in ember-cli now after a few months:

• I find the test reporter annoying. There is another in the pipe, but its waiting on an ember-cli bug which is supposed to be released next week.
• I found the default reporter has problems interacting with chrome, which seem new. (Firefox seems better).
• the cool nested "describe" is not exported. I created an issue for it.

---

It seems in short the tooling I recommended is creaky. It does look like the tools are maintained so these issues will get resolved, but I thought I'd give you another shot: to you really want to learn mocha or not? It is nice, but that niceness is a bit obscured right now when working with ember-cli.

[shaunc]

(btw will be mostly "in transit" travelling from Poland -> Boston tomorrow/today)

[shaunc]

As noted, turning tail on ember-cli-mocha. Proposed new organization of tests:

• qunit integration tests
• subdirectory for each section
• (more or less) one file for each sentence
• one module per feature mentioned in sentence

---

spec/defining-the-window/
  height-and-width-test.js

    moduleForComponent(
      'spec/defining-the-window/height-and-width/height', 'control layout by specifying height',
       {integration: true});

    test('set height renders whole to specified height', ... )

---

Any comments?

[BryanCrotaz]

I just added tests in ember-cli-csp-style (and fixed the code, so npm update your ember-grid)

See what you think of my test style.

[shaunc]

They look good to me.