Should Tinytest tests be order independent?

testing
1

Hey all, trying to learn some Meteor best practices for package testing.

I’ve recently been working on a package that’s pretty seriously state dependent. While writing tests, I’m finding that tinytest’s lack of beforeEach and afterEach utilities make it a bit of a pain create fresh objects for each test. Is it better for me to just make the tests ordered and deal with that, use something outside of tiny-test (:(), or something else?

Cheers.

1 Like
2

Maybe there is an issue in your code which makes it not easily testable?

3

It’s in pretty early stages right now, so like, sure, but I can’t really think of how to approach what I’m doing without being pretty object-oriented. By your response though, I’m assuming they should be order independent?

I basically have like:

// some exported singleton ExportedClass
Tinytest.add('blah', function(test) {
  ExportedClass.someFunctionThatModifiesExportedClass();
});

Tinytest.add('next test', function(test) {
  // what do now
});
4

You can use mocha to test packages instead. You may want to take that approach. I think it works with the tiny-test commands if my memory serves me right.

2 Likes
5

Yes they should be independent if you are doing unit testing at least. For end-to-end-testing it’s kinda different.

I don’t totally get your example, can you give a real example with some code?

6

Personally, I’m using https://atmospherejs.com/practicalmeteor/mocha to test all of my packages now, and I get nice before/after hooks.

I’d reset all of the global singleton state between every test.

7

I’ll probably end up just using Mocha, but the gist is that I have a class that manages multiple user locations, and it needs to be initialized with functions to be called on location updates and how to store the location. There’s a bunch of utility functions I wrote for this manager (e.g. I have one that updates some information for the current user) and I wanted to test each of them, but I wanted to avoid repeatedly reinstantiating the manager with the same functions.

8

We use just a simple function in the tests which returns a new clean instance. So we don’t repeat that code.