TensorOps test simplification

[corbett5]

The current tensorOps tests are to their benefit

• Exhaustive.

and to their detriment

• Complicated. They involve heavy usage of macros and are spread across multiple source files.
• Slow to compile, maybe a minute or two with NVCC and super long with Intel or XL (not that I really care about those).

This is proving to be the part of LvArray that is touched most frequently by other developers and as such I would like it to be easy to add tests. If there is an existing test that is similar to the new function copying works fairly well, but due the unique file structure it can be hard to find a specific tests, and if there isn't a similar test writing one from scratch is non-trivial.

Currently much of the complexity arises from my desire to test all of the template functions with many of the possible argument permutations. For example to test the trivial copy I test all nine permutations of ArraySlice< T, 1, 0 >, ArraySlice< T, 1 -1 > and T[ N ]. This test is then instantiated for three different combinations of T and N, and another 3 when using CUDA. Just looking at the code for copy it is pretty obvious that it is correct so this seems like overkill, the purpose of the tests is as much to verify that things compile as to verify runtime correctness. The template explosion leads to long compile times and I've spread the tests across multiple translation units to make it faster.

I'm starting to think that it might be worth decreasing the test coverage if it could significantly decrease the barriers to entry. What has been your experience adding tests, was there anything in particular that took some work to figure out?

Tagging people who have added tests:
@klevzoff @francoishamon @CusiniM @rrsettgast

[CusiniM]

So, in my opinion the tests are indeed a little complicated but they are also very well structured and I didn't struggle that much. I guess that testing all these permutations is the main source of confusion but it is also convenient if it protects us from having complicated compilation errors later on. Personally, I do not mind the use of macros.
It is true though that these unit tests take long to compile and decreasing a bit the coverage may be worth it. I guess that, for example, to check for compilation errors there is no need to test all permutations in all functions but it could be done only in a couple of them.

[corbett5]

@CusiniM thanks! I think the easiest way to reduce the compile times is to

1. Reduce the number of typed test instantiations. Use say int32[ 1 ] and float[ 4 ] on host and then int64[ 2 ] and double[ 3 ] on device. This should speed up compilation by a third but wouldn't simplify things.
2. Come up with a better way to separate the compilation of each test. Perhaps this is best done by making use of CMake configurable files (RAJA does this). I think this could be done in a manner that both reduces compile times and makes it easier to add a test.