We are writing a v8 addon for node.js.
The addon (as you may well know) is a C++ dll.
How do we unit test this?
The simple way is to use node.js scripts to call our exported functions from the addon dll. But this is not a true unit test, as it's across languages.
Has anyone managed to successfully write a C++ unit test for their addon dll?
We have tried, but are getting unexpected errors - we suspect this is because the node-gyp libraries expect everything to be called in the context of node.exe, and because our unit test uses the addon dll "standalone", some things are not getting setup correctly, causing the test to fall over.
If you have managed to use C++ unit tests for v8 addon, please can you detail the best way to do it, and things to look out for?
regards,
Stretch
I was thinking about this, too. But unless you have really lot's of cpp-logic it's perfectly fine to just write cpp-js-combination and unit test the js-implementation as can be observed in the Nan-library, here. Having less logic means here, that the cpp-implementation in the best case is anyhow just the API glue.
When you do have custom logic and write Nan#2-style classes (so, straightforward cpp) you can of course test it the like regular cpp by including it's headers and do some...
void testEquality()
{
CPPUNIT_ASSERT( /* some test*/ );
}
Related
I have an emscripten/webassembly wrapped C++ class that launches and uses pthreads internally. It generally works fine when used in javascript on Chrome in its stand-alone development sandbox. However, I can't really get it to work with create-react-app and webpack (i.e. I used react-app-rewired to be able to configure webpack).
The problem seems to be from the complexity of the javascript and wasm files that a threaded emscripten build creates, and the confusion those scripts have due to the renaming of files that webpack produces. The files produced for a multi-threaded emscipten build are:
MyModule.js
MyModule.wasm
MyModule.worker.js
I can (I think) get it to work in the non-threaded mode where there is just a MyModule.js and a MyModule.wasm file through the use of the Module's locateFile method. However, the system gets very confused due to the introduction of the new MyModule.worker.js file which the MyModule.js file launches on its own within a WebWorker. And of course the MyModule.worker.js file needs to also find and get access to MyModule.wasm, and that gets lost too (i.e. can't find the right file name due to the webpack renaming).
Anyway, I've spent hours searching the web for any successful use cases like this, and trying may things, including manually editing the MyModule.js and MyModule.worker.js files, but without any luck so far.
Has anyone successfully tried something like this, or any other advice on getting a multi-threaded emscripten/wasm build to run properly with webpack (or create-react-app)? Any advice would be greatly appreciated.
NOTE: This question isn't about running a emscripten/webassembly module in a web-worker thread (although in the end I'm going to run all this in a web-worker). Its specifically about a multi-threaded emscripten build (i.e. C++ with pthreads) launching and running properly with webpack.
In Module's locateFile, you should return the correct path for MyModule.wasm and MyModule.worker.js.
Besides, In Module's mainScriptUrlOrBlob, you should assign the path for MyModule.js.
The mainScriptUrlOrBlob is used in worker for loading the wasm.
I'm pretty new to ServiceStack, so apologies in advance if the nomenclature is not 100%.
I create a test self-hosted application and the ServiceStack Service was in the same assembly as the mainline code. All good.
I then moved the code to production use, and service now lives in a separate assembly to the main code. Initially, I have a test harness that I use to make sure everything works fine, and then a windows service that references that same assembly. Fairly sure this would be normal usage.
The test harness works fine, however for production use, I have used Fody Costura to embed the assemblies into a single executable (makes it easier to copy from dev machine to production machine was my thinking).
When using Fody Costura to embed the assembly into the executable, ServiceStack returns an error during the Init() (invalid path). I have tested this and it seems that the ServiceStack Service class needs to be in a physical assembly file that can be loaded, and not a resource.
Is there are known work around for this, or do I need to retain the code in its own assembly for ServiceStack to work?
Thanks in advance.
Craig
I'm not familiar with Fody Costura impact, but the ServiceStack.Gap project shows how you can ILMerge ServiceStack into a single cross-platform .exe.
A pretty common problem with any kind of integration test is getting the unit under test into a known state -- the state that sets up well for the test you want to perform. With a unit test, there's usually not much state, and the only issue is in potentially mocking out interactions with other classes.
On the other hand, when testing a whole app there's all sorts of potentially persistent state, and getting the app into a clean state, or trickier still, into a known state that isn't "clean" without any access to the app itself is a little tricky.
The only suggestion I've found is to embed any necessary setup in the app, and use something like an environment variable to trigger setup. That is, of course, viable, but it's not ideal. I don't really want to embed test code and test data in my final application if I can avoid it.
And then there's mocking out interactions with remote services. Again you can embed code (or even a framework) to do that, and trigger it with an environment variable, but again I don't love the idea of embedding stubbing code into the final app.
Suggestions? I haven't been able to find much, which makes me wonder if no-one is using Xcode UI testing, or is only using it for incredibly simple apps that don't have these kinds of issues.
Unfortunately, the two suggestions you mentioned are the only ones that are possible with Xcode UI Testing in its current state.
There is, however, one thing you can do to mitigate the risk of embedding test code in your production app. With the help of a few compiler flags you can ensure the specific code is only built when running on the simulator.
#if (arch(i386) || arch(x86_64)) && os(iOS)
class SeededHTTPClient: HTTPClientProtocol {
/// ... //
}
#endif
I'm in the middle of building something to make this a little easier. I'll report back when its ready for use.
Regarding setting up the state on the target app there's a solution. Both the test runner app and your app can read and write to the simulator /Library/Caches folder. Knowing that you can bundle fixture data in your test bundle, copy it to the /Library/Caches on setUp() and pass a launch argument to your application to use that fixture data.
This only requires minimal changes to your app. You only need to prepare it to handle this argument at startup and copy over everything to your app container.
If you want to read more about this, or how you can do the same when running on the device, I've actually written a post on it.
Regarding isolating your UI tests from the network, I think the best solution is to embed a web server on your test bundle and have your app connect to it (again you can use a launch argument parameterize your app). You can use Embassy for that.
I looked into various frameworks for writing unit tests for an application developed in node.js. There exists multiple options like: nodeunit, jasmine-node, should.js library in Mocha. All seems to be pretty much capable of testing everything. I couldn't find any limitation of any of above mentioned options.
I will prefer to use nodeunit as it seems easy to use as a beginner. Any suggestion about any limitation of nodeunit would be highly helpful before I start working on this. Or any suggestion if anyone thinks that there exists a easier and better option for unit testing in node.js.
I previously used JUnit in Java and want to find similar testing framework. It was hard for me to getting started with BDD frameworks like Mocha. Finally I stoped on node unit. All advanced functions which I couldn't find in node unit was finded in expect.js. Also important testing framework in web application context is superagent(which helps to make requests, and get responce on tests), it was easy to mix with node unit, and easy to test async code. One more nice thing there is plugin for WebStorm :)
Can you use the InternalsVisibleTo assembly attribute in a AssemblyInfo file of a MonoTouch Library to allow MonoTouch Unit Test (Touch.Unit) access to the internals of the MonoTouch library?
This is something that is great to use in non-MonoTouch world to allow testing of internals without having to jump through hoops. However I am not able to get it working with a MonoTouch Unit Test. So before I go any futher I figured I would ask if it is even possible, since this is an iOS Application that is the test runner, so not sure if an iOS application which is compiled to native code can even do this.
Yes, it should (or it's a bug) even if I do not recall trying it myself.
The key point is that [InternalsVisibleTo] is mostly a compiler trick and it is supported by the C# compiler (smcs) shipped with MonoTouch (as it's used inside the BCL). As such there's no reason why it should not work from a Touch.Unit-based application.
Now keep in mind that all other rules still applies. E.g. if the the managed linker is enabled when all unused code will be removed (even if marked with the attribute).