Testing decomposition patterns?

testing
1

What’s the best way to break down big functions in meteor? I have a fairly large onCreated function that I’d like to break down and test.

Roughly I have

Template.my_template.onCreated(function(){

Tracker.autorun(function() {

Meteor.call(‘getData’, function(error, result)
{
// do lots of seperate little calculations with the data
littlefunction(result);
anotherlittlefunction(result)
…
}
}

I’d like to test the seperate little calculations seperately. So what’s a good way to decopose and expose the little bits of functionality.

  • I’ve thought about helper functions, but that seems like overkill and its a pain to call helpers from inside templates.
  • I’ve thought about const functions at the top of the file, but then they aren’t well exposed for testing.
  • I’ve thought about hanging functions off the instance but that probably doesn’t work well with testing.
  • I’ve thought about a global function store similar to Template where I could do some MyFunctions.my_template.littlefunction = function() {} but don’t particularly want to do globals

I’m thinking the best way may be to off Template, so Template.my_template.littlefunciton - function(){}
That’s not completely awful and can probably work with testing, iI may be worried about name conflicts but can probably control for that.

Hoping someone has a better pattern.

Thanks

2

So after some research it looks like the best way to do this is to extract as much stuff as possible into “reusable” libraries.

export const libraryfunction = {
littlefunction(result){};
anotherlittlefunction(result){};
}

Put that in its own file and its super easy for unit testing and then wire it into the template.

import {libraryfunctions} from ‘…/afile’

Template.my_template.onCreated(function() {
Tracker.autorun(function(err, result)
{
libraryfunctions.littlefunction(result);
libraryfunctions.anotherlittlefunction(result);
}
}

It feels imperfect, but there’s a lot of overhead in trying to set up the test harness to deal with the template.

The other nice thing I’ve noticed since I started is this pattern does a very good job of forcing good decomposition habits on the functions.

I’d still like to be able to test the autorun and tracker stuff itself, but I think that may only be really testable at integration level.

Still looking for advice on good patterns, but this seems to have been a good direction for the most immediate unit testing of calculations and such.