Velocity Configurable Directories

testing Velocity Core
1

I find the current folder structure for Velocity to be very cumbersome and verbose. It would be really nice if we could use the tests/ folder from inside the client and server directories if wanted.

Another great config option would be to specify if you want to use Jasmine or Mocha for all unit(int/etc…) test folders. This way you’re not deeply nesting all the time.

I understand why it’s not a default but it would be a great opt-in feature to clean up the code and provide better organization (it almost feels like having a top level JS folder all over again)

I’ve added to an issue on Velocity Here

If we had those then our tests would look more like this:

client
├── components
│   ├── CommentsForm
│   │   ├── CommentsForm.js
│   │   ├── _CommentsForm.scss
│   │   ├── CommentsForm.html
│   │   └── tests
│   │       └── unit
│   │            └── CommentsForm_Spec.js

and

server
├── services/
│   ├── EmailSender.js
│   ├── FindFriends.js
│   │   └── tests
│   │       └── integration
│   │            └── EmailSender_spec.js
│   │            └── FindFriends_spec.js
1 Like
2

I’ve been working on this general problem for the past couple of months now… specifically, how to package a component, provide test coverage for it (in my case, acceptance/validation test coverage), and then move files from the package into the tests/ folder so they can be run.

My solution was to create the starrynight command line utility that has scaffolding utilities which can clone a repository and copy files into the correct directories. That way, a package can store files in the manner you are suggesting, but a command can be run that will extract the files into the /tests folder.

starrynight create --package foo:mypackage --from /path/to/component
The starrynight create command is a refactoring tool which will take the files within the client/component/commentsForm directory, and move them into a /packages/commentsForm and scaffold a package for you.

starrynight pattern --url http://github.com/myaccount/myrepo
Once published, the starrynight pattern command will clone your repo into the /packages directory, and then copy the test files within it into the /tests directory. Well, the nightwatch tests anyway. It would be simple enough to add mocha and jasmine support; just copy the lines 49 through 62 a couple times, and specify the relevant directories.

There’s lots more approaches like this we could do. What if tests were stored within a .tests folder within a component directory? We could write a script that parses through the /client and /server directories, and extracts all of the files within .test subdirectories into the /tests directory. Then we could run that script as part of the build pipeline, and they’d be refreshed each time the Meteor app restarts.

You might be interested in taking a look at the clinical:hipaa-audit-log package to see a component-scoped tests directory in action. I was rather pleased with how it turned out, as this approach allows me to provide API extensions in each package README. That is, it allows us to say 'This package provides the reviewHipaaAuditLogPage() Nightwatch API`.

2 Likes
3

Interesting!

The only problem is I don’t think that workflow would work well for non-package items as they would have to be moved every time the file changes, correct?

4

Yup. But keep in mind that the bundler already does that. Change a file, and the bundler rebuilds the application. So it would be necessary to attach the script to the build pipeline, which is done with Package.registerBuildPlugin() or by extending the meteor tool with a custom track/release.

It works a little better for acceptance and validation testing, rather than unit testing, since there’s not necessarily the same assumption that one wants to rerun all the tests anytime any file is changed. But it’s food for thought.

5

Short Answer
Is it possible with Velocity? Yes
Is it supported? Not today!

Long answer
Velocity allows frameworks to specify which directories should be considered source files by Meteor. The way this is done is using a forked version of Meteor that we created that only runs the mirrors. You can see an example of this testsPath parameter being used here. Currently this only works relative to the /tests directory. It would be possible to do what you’re saying by modifying the fork above to also include files under any tests directory within the app as source files. This would involve some more surgery in the forked meteor.

Other solutions that try to copy/symlink files for you are a bad idea. In general we don’t get Velocity to move things around on the users behalf. We had our fingers burnt with the test-proxy before when we added a package for users. Every developer has their own unique workflow and nobody like a tool messing with their files and folders!

The case you’re asking for is something I’d really like also. I personally organize my folders in a feature fashion like this and my tests have exactly the same structure under /tests like this. I’ve been thinking that grouping features and their tests together makes more sense when build app-level tests. In Meteor land the testing of “components” is done at a package-level and with your suggestion if can also work at app-level. I’d also like to integrate this approach with a feature-flagging solution!

I agree that supporting a mix-and-match approach to suite the developer preference would be a great addition. I’ll discuss this issue with the Velocity team in our Thursday meetup and I’m tracking this issue as an enhancement question here

6

Wow thanks for the detailed feedback @sam !