make the code user friendly?

[ghost]

Cool stuff bro! And fast!!! But what scares me to hell is the tons of extra code you need to add to due a simple test! What about making it user friendly bro?

• Instead of forcing closures on the end user. Simply return function () {} and you do the heavy stuff out of sight for the end-dev? as in jasmine, mocha etc.
• improved logging - see mocha. Maybe you could add a reporter option?
• in the source. test/helper. Simplify this files so they are not needed? Let the CLI handle this kind of stuff? Should it be needed to call the teenytest main function from here once more when the CLI does it? See helper.js.

logger-factory.js. Can't this be baked into the source? Let the asserts be a simple plugin that include assert.js. And plugin options for other to create their own assert library if needed?

I think bro all this things scare people off. I guess your intention is that end-devs - not nerds - should use your absolutly great code?

What about debugging bro?

Other cool stuff to consider...

• time stamp when test start. File size maybe, and the time consumed for each test / file or module.
• support for testing other files then .js. Example coffee, typescript ( hot topic this days) and livescript, dart etc.

Damn cool bro if I cun only run the test directly without extra code!!!

And cool cool stuff bro! I'm loving it!!

[searls]

Thanks for the lighthearted stream of consciousness appraisal, Jon. I'll try to pick out a few parts to respond to next time I'm at my computer.

[ghost]

Hi again bro! Yeah nice if you could make a few changes! I just noticed that your index.js file in the root is suspiciously similar to the code inside test/helper folder.
So my suggestion is that bro if you give your superb code a brain so it become super smart, and can do all this crazy stuff out of sight for everyone. This code will be a winner!!

[ghost]

Here bro is a few more suggestions!!

When you run tests today, you are invoking the test/helper function. Isn't the tennytest that is the engine here, and not the helper?

So my idea is that you replace helper.run('test/fixtures/basic-*.js', function (er, result, log) {}
with teenytest('test/fixtures/basic-*.js', function (er, result, log) {}

So then bro teenytest need a little change so it's second argument is either userOptions or nothing. Nothing sounds bad :( So if you have a default object with default settings, you could merge that with options by user.

var defaultOptions = { ... }
var userOptions = { ... }

So if you run teenytest without options, it will fallback to defaultOptions by default.

Then me - as end-dev - only need to run teenytest, and I know it will have 3 arguments.
At least this make my life much easier :)
What do you think, bro?

I also saw this // 3. run the tests in the index.js file. Here you could add a reporter plugin. And by default in mentioned defaultOptions you could have

js var defaultOptions = { reporter: }

I just see this from a user perspective bro. I'm not so good at the internal stuff!!!

[ghost]

Hi dude! Sorry but I had a rough weekend with the bottles again :( :(
At least I managed to read through your code, and other issues, and have a few more things to mention bro!

• validate path for windows
• emitter events. Even mocha had this from v. 0.0.3. I checked the old code!
• better reporter as mentioned in another issue here
• maybe a progress bar running and the progress for all tests, and when done it say 20/20 tests succeed.

Sorry bro! My brain is fucked up. Love yeah and your awsome code! !

[ghost]

Bro!! Look at this 5 year old mocha code. 5 year!! https://github.com/mochajs/mocha/tree/a4248603b4867171c85123dc1ed94b59392e856a/lib

It is user friendly, have reporters; option for excluding files and emitter.

Nice stuff bro!!

What's killing me bro is your silence and your callback in the test helper folder. It can be in line. Done in test-doubles too bro! And mocha!!

I'm little drunk. Sorry for that bro. Love yeah! !

[ghost]

Hey bro! I scrap this project now. The author seems to be out of radio range or switched off and the repo seems to be pretty dead the last 32 days. Still awsome code bro!

[searls]

There are a lot of disparate issues raised in this thread. I'll try to enumerate them here and either address them or create new issues focused on one thing at a time.

• "forcing closures on the end user" - the purpose of teenytest is to not have a user-facing API (over the years, I've found it to be confusing to beginners and needlessly indirect for advanced users), so if that's something you value, then I don't think this is the tool for you
• Better reporter, progress bar - TAP13 has been fine for me, but new reporters can be accomplished by writing a reporters-scoped plugin. (Plugin info here). It could be implemented as a separate module
• Not liking the test helper that invokes teenytest - This hasn't caused any issues and has enabled some easier assertions. If I invest the time to change it, I'm more likely to change each test to spawn a child process so that I'm sure it's executing the CLI code properly with options-parsing as well, but it's not a major issue IMO
• logger-factory refactor - this predates the existence of the plugin API; it's possible that it could be reimplemented, but it's a test-scoped helper and does it's job as-is. Beyond that, I don't think the test should rely on the subject for all its assertions (it shouldn't trust the plugin system is working in this case, which could lead to false positives and hard to debug true negatives)
• Default options not merging - Invoking teenytest via its API allows you to invoke it with two or three args, I'm honestly unsure what you're asking for or for what intended benefit. Feel free to open a PR to clarify
• Windows support - Good point, tracking this with Get the build onto windows #26
• emitter events - This is planned and tracked by Add reporting hooks that conform to js-reporters #15
• "option for excluding files" - is already tracked by ignored glob option (e.g. in node_modules) #13

Locking this thread because it covers too many topics to have a productive, focused conversation. If you want to raise any of these specific points elsewhere, feel free to open an issue with a linked example project to demonstrate the issue or send a PR.