Better Test Runner
Opened this issue · 7 comments
Right now we have this TestRunner project which just runs unit tests (https://github.com/nick-thompson/blueprint/blob/master/examples/TestRunner/Source/Main.cpp). The only unit tests we have are a couple of tests on the EcmascriptEngine to verify that our interface on top of Duktape works correctly.
This is helpful, but... not that helpful. I think what would be more useful is the following:
- Convert the TestRunner project to CMake (it's not already, I believe)
- Write the Main.cpp such that it just spins up an EcmascriptEngine and evaluates a javascript bundle passed to it via args as a CLI (e.g.
testrunner path/to/bundle.js) and asserts that there are no errors in evaluating that bundle. - During our CI, we'll cmake build all projects, then run through GainPlugin's
npm install/npm run buildflow, then finally test that the resulting bundle runs without error in Duktape by invoking our newtestrunner GainPlugin/jsui/build/main.js.
The only gotcha here is that we'll have to make sure that BlueprintBackend.js can successfully shim the native functions that we would expect to have been installed by ReactAppRoot (the rendering backend funcs). But, that should be totally doable.
Yeah excellent. I think this will add real power and confidence to the CI checks.
I was thinking about this when dealing with the css macro properties, where unit tests for asserting that a particular string produces a particular matrix would be very useful. To run unit tests for react-juce through EcmaScriptEngine would be great - i.e. instead of node running something like jest, which will glob for test files and assemble suites, we build a test bundle using webpack and run that with our test runner. To keep the workflow simple like this (you just write myUnit.test.ts somewhere in the react-juce source and it will get included in the test bundle) I think would be very cool. @nick-thompson do you think that's worth doing and easy enough to do?
I was thinking about this when dealing with the css macro properties, where unit tests for asserting that a particular string produces a particular matrix would be very useful. To run unit tests for react-juce through EcmaScriptEngine would be great - i.e. instead of node running something like jest, which will glob for test files and assemble suites, we build a test bundle using webpack and run that with our test runner. To keep the workflow simple like this (you just write myUnit.test.ts somewhere in the react-juce source and it will get included in the test bundle) I think would be very cool. @nick-thompson do you think that's worth doing and easy enough to do?
Ahh neat, that's a great idea. Yea, I think that sounds easy enough + definitely worth it
Had a proper read of the requests and concepts in here - totally agree with all of it...
I think I have a solid idea on how to tackle all of this with the efforts focused on usability and flexibility.
Excellent @jrlanglois! I think we can split this into two pieces of work: one for the refactor + running the GainPlugin bundle, and then if you want to tackle a follow up pull request for @olidacombe's test bundle that's awesome. That latter one will likely involve some good webpack nudging, which I think is a bit of "scope creep" if we try to fit that all into one pull request.
I'll go ahead and assign your name here so as to prevent duplicate work if someone else finds the issue and feels like trying it
A task to add would be changing from the Projucer project to the cmake project.
A task to add would be changing from the Projucer project to the cmake project.
Agreed! 100%