Suggestions

[ghost]

People who read the documentation will think of thallium in the same way as tape, ava etc. Im one of them. And i link things simple.

Here are suggestion...

1. Now you write t.test() to perform a test. In ava you only include ava and do this:t.test()`. Simpler. Possible?
2. Hooks. . Let the hooks run serially to the tests. Add a context for each hook that get auto reset too avoid pollution.

T.beforeEach(t => {
    return {
        data: 2
    };
});

T.test('My Test 1', (state) => {
    t.equal(1+1, state.data);
    state.date = 3;
});

t.test('My Test 2', (state) => {
    t.equal(2, state.data); //state is still 2, because beforeEach is run individual for each test
});

This including a "state" that is passed down for each test as an argument.

1. Use t as an argument as in ava and tape.
2. Concurrent and serial tests
3. Global api to build reporters as plugins. See js-reporter api.
4. Change reporter in the cli as a flag or through config files. As in mocha
5. Add a cli flag to log errors.
6. Watch mode. A must have
7. Show last run time in humanized format
8. Show filename for test.todo(...)
9. Add a --report flag that gathers all environment info before reporting a bug

[dead-claudia]

@zubuzon

Now you write t.test() to perform a test. In ava you only include ava and do this:t.test()`. Simpler. Possible?

If you'd like, feel free to send a PR on the docs. I pretty much have this feature locked until 0.3 gets published.

Hooks. . Let the hooks run serially to the tests. Add a context for each hook that get auto reset too avoid pollution.

You can do that with a simple wrapper function:

const t = require("thallium")
const assert = require("thallium/assert")

function test(name, func) {
    t.test(name, () => func({data: 2}))
}

test('My Test 1', state => {
    assert.equal(1+1, state.data)
    state.data = 3
})

test('My Test 2', state => {
    assert.equal(2, state.data)
})

1) Use t as an argument as in ava and tape.

I deprecated the argument because of potential issues when you make subtests - it's really easy to forget the t, especially if you normally parenthesize single arguments (I don't):

// Imagine this buried 500 lines down.
t.test("foo", (t) => {
    t.test("bar", () => {
        t.timeout = 10
        return getPosts().then(posts => assert.match(posts, [
            new Post("Title", "Body"),
        ])
    })
})

2) Concurrent and serial tests

Aiming for 0.4.x. Oh, and serial is technically the default.

3) Global api to build reporters as plugins. See js-reporter api.

Already thought of it and added it.

4) Change reporter in the cli as a flag or through config files. As in mocha

I've thought of that; it's just not quite so cut and dry given the architecture of this. I previously had something like the subarg syntax implemented, but I took it out after reassessing it (the concept itself was rather unintuitive initially for my particular use case). I would like to expose something a little higher level than that, but I would need to think of how the API should be.

5) Add a cli flag to log errors.

Test errors are already reported. And internal errors are intentionally fatal (although I do defensively try to keep the state as much intact as possible). I've considered making reporter errors non-fatal, but I decided against it because that can lead to some garbage on top of the exception that also needs reported.

6) Watch mode. A must have

Aiming for 0.4.x.

7) Show last run time in humanized format

There's no reliable way to tell that. Even editing the config destroys the only way you can figure that out.

8) Show filename for test.todo(...)

Presumably, you mean t.testSkip? And that's something for grep, not a test runner.

9) Add a --report flag that gathers all environment info before reporting a bug

That'd make sense for a high-level front-end application like Atom or Yeoman, but not so much for a test runner.

[dead-claudia]

People who read the documentation will think of thallium in the same way as tape, ava etc. Im one of them. And i link things simple.

Those were an inspiration, yes. I'm just hiding a lot of power under the hood, though. :wink:

[ghost]

@isiahmeadows I reading the docs and find the concept interesting even if I can't run any tests :) As I wrote before you caught my interest with this, so I will see if I maybe got some more suggestions for you.

Just now I'm in Charleston, West Virginia. On my way to Five Guys Burgers and Fries to get some breakfest. I will read the docs again after that.

[dead-claudia]

Ok. Nice! (Five Guys is awesome, BTW :smile:)

[ghost]

@isiahmeadows

I'm stuck in a bus terminal, so I got some time to look at things. Here are a few more suggestions from me.

1. src/settings.js. Variabels are identical to function names. E.g. windowWidth is both a variabel and function name. Maybe change this?
2. Convert to TypeScript and fix all block-scoped variable issues if any. And maybe other similar issues.

3. As mentioned on Gitter. Simplify config file. The way the config file is to day, I think that will be one of the mayor obstacles preventing users to move to Thallium. Cleaner way:

   {
   reporter: 'spec'
   }

   and maybe move it to package.json? As many libraries now have done. I also got confused when I had to set the config file as a .dot file.

4. Remove r folder for reporter. Put them in a folder inside the src folder, and use them intarnally without user having to specify path in config. Also expose API for creating reporters. Then in the config - if user specify a reporter - first check node_modules too see if the reporter exist as a plugin, if not fall back to the three core reporters. Karma have done similiar as I'm thinking now.
5. Documentation on how to write your own plugin and what the purpose are. which kind of plugins can be created, and for what purpose?
6. Documentation on how to use Thallium with Karma
7. Move "deprecated" APIs to plugins or separate modules.
8. Add a ignore option to config file. As I did in my clisiah demo. So if folders or files should be ignored, user could simply do:

{
ignore:  "!**/node_modules/**"
}

to avoid writing complex GLOB patterns everytime, and they will always know that this files / folders are ignored by default.

1. Same as 6. But add all CLI flags to config, so user can set them by default without need to specify them everytime using the CLI.

[ghost]

@isiahmeadows I'm gone again. Today I'm going home to where I'm born and are going to meet my parents and siblings again. I haven't seen them for 8 years :( So it's time for ZubuZ to return where he belong!

I'm offline now.

[dead-claudia]

Here's my answers to those suggestions, whenever you become available again:

1) src/settings.js. Variabels are identical to function names. E.g. windowWidth is both a variabel and function name. Maybe change this?

That's by design. (I'm guessing you mean lib/settings.js.) The reason is because the functions are exposed-by-reference getter/setter pairs of those variables. I could accomplish the same by exporting a bunch of these, but a function is more convenient.

2) Convert to TypeScript and fix all block-scoped variable issues if any. And maybe other similar issues.

1. ESLint already checks blocks, even though it's ES5. I have this particular rule enabled, so it'll be fairly painless to migrate the scoping. To be specific, here's a list of all but two rules I use, the other two being set here.
2. TypeScript migration is already on the roadmap. Most of the complexity will be migrating everything to reuse the original structure.

2.1) As mentioned on Gitter. Simplify config file. The way the config file is to day, I think that will be one of the mayor obstacles preventing users to move to Thallium. Cleaner way: [[code]]

I'm intentionally declining that, and here's why: I want the test configuration to remain as far away from the CLI as I can get it. This is why the config only has two exports, both optional: thallium and files. What I've done is forcibly separate the CLI from the initialization, and make it clear that you use code instead of config. I'm actually considering as part of 0.4 to add a files getter/setter to the instance (only used by the CLI), and just having the user default-export the Thallium instance if they're using a wrapper.

I'm taking a very highly opinionated stance on the code-vs-configuration and convention-vs-configuration approach. It's so much simpler to make everything code instead of writing out a JSON-flavored JS file that spans 100+ lines. Consider Gulp vs Grunt as a really good example of this. Also, I want to allow both tl test.js and node test.js, without issue and with the same look and feel (you don't need a runner for a small 200-line project - this is why Tape is so popular).

2.2) Remove r folder for reporter. Put them in a folder inside the src folder, and use them intarnally without user having to specify path in config. Also expose API for creating reporters.

1. I'm keeping the r folder, because I want to have an easy way to specify things.
2. The heart of it is already in the lib/reporters folder. The rest amounts to literally about 200 SLoC (excluding the unfinished DOM reporter that will almost triple it when done).
3. The reporter API has been exposed publicly since 0.1, and its interface hasn't really changed a ton since. Feel free to compare that to what it is now.

2.3) Documentation on how to write your own plugin and what the purpose are. which kind of plugins can be created, and for what purpose?

Done.

2.4) Documentation on how to use Thallium with Karma

I'll get to that later. That will literally require writing a whole new plugin first, which is quite frankly low priority ATM. Maybe after 0.4/0.5, I'll write it, but not yet. (It'll also prove to be a useful real-world reporter/plugin combo example.)

2.5) Move "deprecated" APIs to plugins or separate modules.

That's what the thallium/migrate module is for. It monkeypatches the old API in as best as I could while still enabling the most current API to work.

2.6) Add a ignore option to config file. As I did in my clisiah demo. So if folders or files should be ignored, user could simply do: [[code]]

Negative globs in your files is how it's done:

exports.files = ["test/**/*.js", "!test/{fixtures,util}/**"]

I really should fix how they're checked (the globs are ordered highly inefficiently), but that's the basic idea.

3) Same as 6. But add all CLI flags to config, so user can set them by default without need to specify them everytime using the CLI.

No need - the same ignored globs still work. Depending on your shell, you may have to quote the glob or escape the preceding ! (e.g. in Bash, probably not in Windows), but it works the same way (and with the same issue I pointed out above).