On 2017-11-15 7:30 AM, Steve Grundell wrote:
> ...
>
> But, why use a test framework for .NET at all - when you're already
> inside jqUnit?
>
> Each jqUnit test can be a wrapper to call the C# test, and the jqUnit
> object can be passed into C# at the start, so you can still do
> jqUnit.assert.
Thanks Steve.
That's the technique used with our Linux code where I previously wrote
that only the exported or interface functions from the C++ add-on are
tested. The way that is done is by calling the JavaScript version of
the exported function code from within jqUnit, and then using assertX()
on the return value. That matches exactly what you are proposing.
A worry is when things go south inside the native code (C++/Linux, or
C#/Windows). That happened with the Windows processes bridge where an
IllegalArgumentException was thrown from within the C# code. When that
happens, no result is coming back to jqUnit. How does one test for that
using jqUnit?
Or, those exceptions should be handled within the native code such that
a result always comes back. I think. Hmmm... What about functions
that don't return anything? Is that an issue?
--
;;;;joseph.
'Call me hobophobic, but I don't think two vagrants should be allowed to marry.'
- J. Tiedrich -
_______________________________________________
Architecture mailing list
[email protected]
https://lists.gpii.net/mailman/listinfo/architecture
