Tinytest Questions (2)


#1

I’m (still) working through Discover Meteor and building the Microscope app. (sorry for all the questions - there is a lot to learn!)

I just reached the Packages chapter and the part about Tinytest. I just have a couple of questions:

  1. The DM book says Tinytest is a “package tester,” so I just want to confirm: it only works for testing packages? Not apps in general? I’ve heard about the Velocity testing package. Is it recommended to use for testing Meteor apps in general?
  2. The book mentioned that the Tinytest package itself is in early development, and thus in flux, with lots of API changes. I noticed also that the code that was generated when I used meteor create --package was different than the example code in the book (i.e. some of the calls to api.use() and api.addFiles() are different in the book than in the generated code. I assume this means the Tinytest API has changed since the book was last updated.

I didn’t see Tinytest mentioned in the official Meteor docs (full API version), and from a Google search, the best result I found was this:

That’s ok - I completely understand if the API is in flux; I just wanted to ask if there’s any other source of official documentation for Tinytest (that possibly I missed)?

Thanks!


#2

Hi!
You have it correct. TinyTest focuses on testing packages, not apps in general.

That being said, it’s possible to write apps that are structured completely as packages; and since TinyTest happens to be the QA testing framework that Meteor uses for internal quality control, you can use TinyTest to test apps… if they’re structured correctly. But if you want something to test the parts of your app that aren’t a package, you’ll need Velocity or StarryNight.

TinyTest has been a weak point in the Meteor documentation for a long time. The API basically boils down to the following:

.notEqual(actual, expected, message)
.instanceOf(obj, class)
.notInstanceOf(obj, class)
.matches(actual, regexp, message)
.notMatches(actual, regexp, message)
.throws(f, expected)
.isTrue(actual, msg)
.isFalse(actual, msg)
.isNull(actual, msg)
.isNotNull(actual, msg)
.isUndefined(actual, msg)
.isNotUndefined(actual, msg)
.isNaN(actual, msg)
.isNotNaN(actual, msg)
.length(obj, expected_length, msg)

As I understand things, MDG wanted to swap TinyTest out at some point; and was reluctant about formalizing the API in their docs. The TinyTest API has been available in unofficial documentation via the Meteor Cookbook, in articles such as Writing Unit Tests with TinyTest, and is going to get a full treatment in the next round of StarryNight documentation.

You can see a preview of the upcoming documentation on the starrynight-beta page. We’re adding the TinyTest API as Nightwatch commands, which will make the TinyTest API isomorphic across validation and verification testing. And with the StarryNight’s autoscanning functionality, it should be available for use on non-packaged server and client code as well. But most importantly, it will be consistent.

Also, be aware of the clinical:verification package, which is an extension to TinyTest, and the practicalmeteor:munit package, which it was based off of. clinical:verification cleans up the munit API a bit and makes it appropriate for FDA regulatory approval.


#3

Thank you. You are most helpful!

I read in the introduction, in the part about app architecture options in Meteor, about building your app completely (or almost completely) in packages. I’m all about modularity and loosely coupled components, so that appeals to me.

However, when I googled quite a bit for “package-only meteor apps” and used related queries, I couldn’t find a lot of tutorials about that architecture. It’s quite possible that my GoogleFu was lacking in imagination.

Do you know of any resources for learning how to structure a meteor app completely with packages for modularity?


#4

Meteor forum threads dealing with package-only applications.
https://forums.meteor.com/search?q=package-only

And a tutorial on refactoring packages from your app.
http://starrynight.meteor.com/examples/refactor-a-package


#5

Wow, that’s what I was looking for. Thanks!

I read through part of your Clinical Working Group project, and some of your posts. You’re quite a prolific developer! How do you find the time to produce so much code? You must either be super efficient, or I’m doing it wrong. :wink: