It's an interesting idea. My first reaction is to wonder how it would work with the more complicated tests you typically encounter in real-world JavaScript.
For example, see [1]. This is a very simple example of testing a JavaScript drawing app. (It's from my Let's Code JavaScript screencast [2].) In this example, you'll see several things that don't seem like they'd work well with inline tests:
1. Common setup and teardown. The tests work against the browser DOM, so there's `beforeEach()` and `afterEach()` functions that set up and clean up the DOM. The `afterEach()` function is particularly valuable because it runs even when exceptions occur. How would common setup and teardown be handled with inline tests?
2. Multiple tests per function. There's a fairly loose relationship between the tests and the functions in the production code. Instead, the tests speak to the behavior of the drawing app. If these tests were inline, how would you prevent the test code from overwhelming the production code?
3. Helper functions. The tests have a lot of helper functions to do things like simulate events and parse the DOM. This particular example is worse than most, but helper functions are still fairly common when testing. How do you distinguish test-specific helper functions from production functions when you're using inline tests?
Overall, I wonder if inline tests would make this code harder to read, not easier.
I'm intrigued by the idea, so this isn't meant to be a middlebrow dismissal, but more an invitation to explore real-world problems. Feel free to use my example code at a starting point! I'd love to see a clever transformation of this code to inline testing.
Comments
It's an interesting idea. My first reaction is to wonder how it would work with the more complicated tests you typically encounter in real-world JavaScript.
For example, see [1]. This is a very simple example of testing a JavaScript drawing app. (It's from my Let's Code JavaScript screencast [2].) In this example, you'll see several things that don't seem like they'd work well with inline tests:
1. Common setup and teardown. The tests work against the browser DOM, so there's `beforeEach()` and `afterEach()` functions that set up and clean up the DOM. The `afterEach()` function is particularly valuable because it runs even when exceptions occur. How would common setup and teardown be handled with inline tests?
2. Multiple tests per function. There's a fairly loose relationship between the tests and the functions in the production code. Instead, the tests speak to the behavior of the drawing app. If these tests were inline, how would you prevent the test code from overwhelming the production code?
3. Helper functions. The tests have a lot of helper functions to do things like simulate events and parse the DOM. This particular example is worse than most, but helper functions are still fairly common when testing. How do you distinguish test-specific helper functions from production functions when you're using inline tests?
Overall, I wonder if inline tests would make this code harder to read, not easier.
I'm intrigued by the idea, so this isn't meant to be a middlebrow dismissal, but more an invitation to explore real-world problems. Feel free to use my example code at a starting point! I'd love to see a clever transformation of this code to inline testing.
[1] The example code: https://github.com/jamesshore/ll11_front_end_unit_testing/bl...
[2] Let's Code: Test-Driven JavaScript, my screencast: http://www.letscodejavascript.com