Let me explain my thinking, in code..
c#:
public something Invoke(dynamic args) {
args.jqUnit.assert("hello");
try {
this.GetType().GetMEthod(args.test).Invoke(this, input);
} catch (Exception e) {
jqUnit.fail(e.toString());
}
}
public void Test1() {
// the test
TheClass tc = new TheClass();
int result = tc.ReturnOne();
jqUnit.assertEquals("hi", 1, result);
}
node:
var testThing = // the edge function
jqUnit.asynTest("asd", function () {
testThing({
})
})
On Tue, Nov 21, 2017 at 2:59 PM, Joseph Scheuhammer <[email protected]>
wrote:
> 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
