Y'all I've been thinking about something. Javascript is great, right? But writing testable javascript is kinda hard. On the one hand, you want to close over your functions so that they don't leak all over your global namespace. On the other hand, once you've done that you can't test any of the functions you've closed over. This is a huge problem!
var computedValue = (function foo(injectedArgument) {
var myLocalVar = 123;
function someSiblingFunction() {
console.log("hey this was called, cool.");
}
function myInnerFunction(x, y) {
var output = x + y + inferred.injectedArgument - inferred.myLocalVar * inferred.someOtherVarThatCameFromWhoKnowsWhere;
someSiblingFunction()
myLocalVar = output;
return output;
}
return myInnerFunction(5, 10);
})(someVariable);
But! When we write tests, especially unit tests, we don't really care about the context in which these functions exist - really, we just want the string of text that represents the function, so that we can run tests against it in isolation. Sometimes (frequently, depending on your coding style) the function may refer to things other than its inputs - calls to things in its scope that were defined somewhere up above ('private' variables closed into the same scope as your function, but as siblings to that function, for instance. Or even just global variables. Or anywhere in between).
So given the snippet above, what if I really want to write some unit tests for myInnerFunction? Right now there's no way to do that, because the javascript interpreter seals that off.
But what if we were to have a completely different javascript interpreter? One whose job was not to take source code as input and create a functioning runtime as output, but rather one whose job it was to detect every function in the codebase and extract it into an isolated context for testing. This shouldn't be THAT hard, right?
We would parse mySource.js and when it got to the closure above it would find function myInnerFunction(x, y){...} and extract it out. It could then go one step further and look at every variable within the scope of that functions internal context and extract them out. So given the source code above, it could generate a new file that looks something like this:
(Note, this is not a proposal for what actual output would look like - I'm just trying to communicate the idea. There'll be some way to cleverly wrap everything up and generate clean tests)
// generated test for function myInnerFunction
// inferred external state - we could maybe even infer sample values, or at least types?
// you can set default values here for tests below, or set them explicitly in the tests.
var injectedArgument = undefined;
var myLocalVar = undefined;
var someOtherVarThatCameFromWhoKnowsWhere = undefined;
var someSiblingFunction = jasmine.createSpy('someSiblingFunction')
function myInnerFunction(x, y) {
var output = x + y + inferred.injectedArgument - inferred.myLocalVar * inferred.someOtherVarThatCameFromWhoKnowsWhere;
someSiblingFunction()
myLocalVar = output;
return output;
}
// implement your tests here
function sampleTest() {
injectedArgument = 1;
myLocalVar = 1;
someOtherVarThatCameFromWhoKnowsWhere = 1;
var output = myInnerFunction(5, 10);
expect(output).toBe(15);
expect(myLocalVar).toBe(output);
expect(someSiblingFunction).toHaveBeenCalled();
}
This works because we recognize a few things:
- A pure function is super easy to test, because you just have to control for explicit inputs and test explicit outputs.
- All functions can be modeled as pure functions if you treat scope as an explicit input and side effects as explicit output.
- Reads, writes and calls to values in the scope can be algorithmically identified and extracted and isolated.
- At the unit test level, we can then treat relevant items in the scope as controlled contexts
Does this make sense? Am I missing something obvious? Because I would absolutely love to add a step to my build which extracts every function in my code and generates test stubs for me to play with. How easy would this be to write?
Ah, I totally see what you're saying and that makes a lot of sense - except now I'm littering my production code with with all of these handles to internal implementation, and my encapsulation has been violated. Additionally, this means that it's not a general purpose solution - I have to write my code in a specific way to be able to do it.
Personally, I do write my code more or less this way - but what if I inherit, say, thousands of lines of legacy javascript with no test coverage? I want to refactor, but first I need to add tests to make sure I'm not breaking anything when I do. But the code wasn't written in a testable way - now I have a problem.
This isn't an esoteric concern, it happens kind of regularly. So, sure, I could slowly start rewriting and adding tests - but then I'm refactoring before testing, so I don't actually have any way to make sure that the things I care about aren't being changed.
So, for this idea, yeah it's going to take a bit more work up front, but the outcome is the ability to generate comprehensive tests for every function in a codebase.
(As an aside: once this works, I can also do crazy shit like extract functions into their own remotely addressable actors and make what used to be a single monolithic JS app into a big distributed app... but that's maybe a can of worms I'll open down the line. ;))