the Fiddler's picture

Add unit tests to the OpenTK.Math

Project:The Open Toolkit library

Right now, there is no rigorous way to test OpenTK.Math. Bugs may difficult to catch and may go unnoticed for a long time.

Is there anyone familiar with NUnit, who can describe how it can be integrated into a project and how to write unit tests for it? Can it be integrated into the build system so the tests run automatically? What kind of functionality can it test?


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
the Fiddler's picture


Thanks, I'll work on this during the weekend. The build system is the main issue, but I think this can work without any invasive modifications.

djk's picture


Ok, I will go get the latest FreeMat installed to help generate test data.

NUnit does not have to be a post-build step, however its nice to have. There is a graphical and console based tool for running the test assemblies. The console tool is used by post-build events, I think that was pointed out above.

Inertia's picture


Since I'm writing tests for some of the methods, might aswell bring this topic up again.

Q1: Is the decision to use NUnit final?

Q2: What's the best course of action to deal with overloads? Should every overload of a method compare it's results to constants, or should the result be compared to another overload? i.e.

public void Vector4BaryCentric()
    a = new Vector4( 1f, 2f, 3f, 4f ),
    b = new Vector4( 5f, 6f, 7f, 8f ),
    c = new Vector4( 9f, 10f, 11f, 12f ),
    u = 0.59f,
    v = 0.72f;
  r1 = Vector4.BaryCentric( a, b, c, u, v );
  Vector4.BaryCentric( ref a, ref b, ref c, u, v, out r2 );
  Assert.IsTrue( r1 == r2 );

...or should this be 2 separate tests?

Q3: Kinda depends on how Q2 is answered. Is it a good idea to do some rough profiling inside these tests? At least to ensure that the elapsed ticks for the pass-by-value overload is higher than for the ref/out ones? I'm aware that the JIT compiler will affect the accuracy of the timing, but it helped as a "2nd opinion by the computer" so far.

objarni's picture


I'd say test one of the overloads more than the other, and also do some tests like yours above, then we will be reasonably sure both are correct.

There is a principle called "triangulation" when writing tests -- it means that for a certain operation/method, having three different "test points" (inputs) is a good "rule of thumb".

For example, Dot-product, test three different input pairs against three different outputs.

If there is type dependence between types, test those without dependencies first (eg. test Vector-types before Matrix-types, if Matrix types depend on Vector). Because if you find errors while testing the Matrix types, it is harder to tell if it is really an error in the Matrix type or in the Vector type.

Technolithic's picture


Hi folks, I'm working on converting a generic implementation of an Arcball User Interface technique for rotating a camera around a scene that works to use the OpenTK.Math library that seems to be putting up quite a fuss in the conversion. Does anyone know the status on the testing for the Math library? If there's anything I can do to help, please let me know.

I was thinking of building small test programs to test the Math libraries with some known-working examples and comparing their outputs. This will enable some fairly exhaustive testing to increase my confidence in where I'm at with beating my head against the wall in converting the Arcball to use the math library. This is the best I know how to approach this right now. If anyone has an easier idea, I'm all ears.


Technolithic's picture


Well, I finally got my implementation working and it appears that I've overlooked a small detail... I'm using the OpenTK.Math library successfully to abstract myself from gross calculations, not to mention keep myself from reinventing the wheel, so perhaps the Math library really does work great. Thanks for building this library, whoever it was! This otherwise complicated beast of a interface has been reduced to so very few lines of code, with the help of OpenTK's Math library.

Inertia's picture


George deserves credit for the mathlib, although it has grown quite a bit it's his initial effort that made it possible :)

Since all 3 Q's remained unanswered, I did not take any further action at that point besides checking that the added overloads work fine. As stated in my earlier posts in this topic I'm having some doubts about the invest-to-return ratio about the unit tests, so I will not be the one pushing this forwards.