Suggestion about a test folder.

[alesch]

Instead of having my code inside lib, I create two folders, src and test.
I can then put the tests inside the package.

[coopermaruyama]

Good idea. I do something like this for personal use, however I use sanjo:jasmine which isn't the default, so I'll need to figure something out that's ideal for all (or most) testing methods.

Ideally I would like to add a CLI tool to add tests which would let you add tests inside each module, (e.g. packages/my-modules/tests/ like you do and symlink it as necessary to work with jasmine, tinytest, mocha, etc. But this would mean evolving the repo from an 'example' to a 'tool' - another thing I need to consider.

I know meteor reserves the 'tests' directory in app root for tests - is this also true for packages? I've always had to symlink into tests/jasmine to get things working right..

[alesch]

I don't think you need the symlinks. With this setup you run your tests with meteor --test-packages, and all frameworks support this. This support is actually better than the one for tests at the app level.

This is relevant even for end-to-end tests, if they are possible to test.

[coopermaruyama]

Alright so I tried testing within packages using this structure a little bit and I noticed that my helpers in tests/jasmine were not available to me inside my modules, which makes sense since it's isolating the package.

To keep in line with the purpose of this package I would like to keep this open until either I or someone else can add a utility package which you would api.use() when testing to get access to a bunch of tools/workflows specifically for working with large codebases. Ideally this would also introduce an easy way of getting the fixtures you need without having to make too many of them manually. I haven't really seen a big meteor project yet which consistently incorporates TDD (Telescope only has like 3 files in tests/jasmine) so I don't know what would be 'useful' for large applications.

[alesch]

Maybe having a test-lib package with your test helpers, that you can api.use()?
Setting debugOnly: true in package.js would prevent it being packaged for production.
See: https://velocity.readme.io/docs/data-fixtures.

[coopermaruyama]

That's exactly what I had in mind. I'm going to play with this for a bit,