I think default build path should be build/*

[matthewmueller]

That allows you to have multiple files in test/ and just run:

$ duo test/*.js && duo test browser

[yields]

so you would have multiple builds ?

[stephenmathieson]

i'm using multiple builds:

$ tree -L 1 build
build
├── build.css # my styles
├── build.js # my actual "build"
├── components
└── tests.js # my built tests

1 directory, 3 files

[yields]

hmm ^ looks like you only want to include tests.js in index.html no ?

[stephenmathieson]

yep:

test: build/tests.js
    @$(NODE) $(BIN)/duo-test \
      --build $^ \
      --reporter spec \
      phantomjs

[yields]

i'm fine with supporting multiple builds, but what's the use-case here ?

[stephenmathieson]

well, i'm using --build /path/to/my/built/tests.js, so what i need already works haha

im not sure what @matthewmueller wants with multiple builds, but i just thought i'd chime-in and give my 2¢

[matthewmueller]

@yields actually not sure if this works in browser, but even in duojs/duo we have separate test files the api, cli, and parser.

[stephenmathieson]

@matthewmueller yeah, multiple test files makes sense, but i don't think building multiple test files is a good approach. see this example makefile (specifically the $(TEST_ENTRY) target) for how I'm handling bundling multiple tests.

basically, i generate test/index.js, which is nothing but a bunch of require('./test/file.js')s. this way, duo picks up all of the requires in test/index.js and builds to ./build/tests.js. the test/index.js acts as the test entry or boot.

edit: also see https://github.com/segmentio/facade/blob/master/test/index.js, which looks like it's just a hand-edited version of the above concept

[yields]

i agree with @stephenmathieson, seems like most users will have a single test file, since most components are really small or should be really small.

[dominicbarnes]

Just wanting to weigh in here, as I'm having trouble getting started, and I think this library could be even easier to use.

I think that duo-test(1) should have a similar signature to duo(1). (not to mention other similar libraries like mocha(1) and duo-serve(1)) Right now, the assumption seems to be that you use a build.js, which I seldom do. (and wasn't expecting to be the default)

I think you should need to specify the entry files you want to test, defaulting to test/*.js like mocha does.

$ duo-test phantomjs
# runs tests in test/*.js

$ duo-test phantomjs test.js
# runs tests in test.js

This would remove the assumption of using build.js and makes it more consistent with the duo and mocha tools under the hood.

[dominicbarnes]

And for what it's worth, even the small libraries that I write often have multiple files within a lib directory, each with a corresponding test file under the test directory.

Thus, I don't think multiple entry files for testing necessarilly means a component isn't "small" anymore.

[yields]

i agree with @dominicbarnes on this, now i remember that's how component-test worked i think? and i loved it haha.