foo_test.ts comes from Google Python style.
foo.test.ts seems to be used in the React community.
The test runner will have this hardcoded into it, I think it would make sense to have a small debate about which is better.
For comparison here's list of glob that AVA matches
**/test.js
**/test-*.js
**/*.spec.js
**/*.test.js
**/test/**/*.js
**/tests/**/*.js
**/__tests__/**/*.js
I've always kept them seperate, in /test/ or /tests/ 馃し鈥嶁檪 but if you are co-mingling, it does seem that foo.test.js is more common these days in JavaScript land.
Yep I also personally prefer the *.test.js pattern. I would imagine maybe in some stupid cases I would name a file bot_test.js which is just a playground script for some bot tools but not a test; I would definitely not do bot.test.js for that purpose.
*.test.js feels more of a "super" extension, while *_test.js keep test as part of the filename thus less strong and subject to more interpretations.
Similar to ava, the coverage tool istanbul considers the following patterns as test scripts and excludes them from coverage reports by default:
test{,s}/**
test{,-*}.{js,cjs,mjs,ts}
**/*{.,-}test.{js,cjs,mjs,ts}
**/__tests__/**
These don't include *_test.ts. I'm afraid that probably *_test.ts pattern would look a little surprising to the majority of JavaScript community.
The JS community normally uses dash case for files, Deno uses snake case internally. Either one would look strange here. This is side-stepped by *.test.ts, as another benefit.
By the way, are we open to switching to dash case for TS files...?
For a jser, *.test.js pattern is more common.
The reason that the React community uses *.test.js is because a project using React mostly consists of individual components that can be tested reasonably in isolation, without a ton of supporting infrastucture.
I find that my tests in Node end up being a little different, since Node projects have a variety of purposes and architectures. For example, if my project is a real-world web app, the tests for my route handlers often need an actual server, database, seed data, etc. Colocating all of this extra stuff alongside my actual API feels much more messy, as does importing them from far away. So instead of having *.test.js, I usually have miscellaneous types of tests and other files in a test directory. The same should apply to Deno projects.
The patterns *.test.ts or *.spec.ts are more common in the JS community
I think there are two distinct questions here:
I don't have an opinion on 1. but for 2. I think that the test runner needn't enforce whatever choice is made. (I don't see a downside to having a large glob.)
Is there a decision on this? After going through the comments, *.test.ts seems to be the favorite.
It'll be easier to rename test files now, as more tests will be added as deno matures.
Deno now automatically discovers test file with following names:
"*_test.ts",
"*_test.tsx",
"*_test.js",
"*_test.jsx",
"*.test.ts",
"*.test.tsx",
"*.test.js",
"*.test.jsx",
"test.ts",
"test.tsx",
"test.js",
"test.jsx",
Both patterns from original comment are covered, so I think we can close this issue.
Most helpful comment
Yep I also personally prefer the
*.test.jspattern. I would imagine maybe in some stupid cases I would name a filebot_test.jswhich is just a playground script for some bot tools but not a test; I would definitely not dobot.test.jsfor that purpose.*.test.jsfeels more of a "super" extension, while*_test.jskeeptestas part of the filename thus less strong and subject to more interpretations.