Unit Testing - std binaries or shaders programming, do you do it?

iroboto

Daft Funk
Moderator
Legend
Supporter
Just curious as we have a bunch of different types of programmers on this forum.
But how many of you do unit testing in the formal sense, building actual tests?

And do shader programmers also do unit testing?


just curious if you've found unit testing to be very helpful, or very time consuming and overall not as helpful?

thanks!
 
We had unit tests for all core (hardware API) rendering functionalities. Makes porting to another platform much easier. Well defined core tech functionalities are easy to unit test.

I wouldn't personally write unit tests for higher level rendering code (rendering a viewport, rendering shadow maps, lighting, etc). Tests like this become very large (big code coverage) and tend to need big test data sets. Adds too much inertia to code refactoring.
 
I would steer clear of the STDs mate. Some of them are permanent.

Lol it took me a long time to figure out what you meant until I looked back at my title. Lol


Sent from my iPhone using Tapatalk
 
We had unit tests for all core (hardware API) rendering functionalities. Makes porting to another platform much easier. Well defined core tech functionalities are easy to unit test.

I wouldn't personally write unit tests for higher level rendering code (rendering a viewport, rendering shadow maps, lighting, etc). Tests like this become very large (big code coverage) and tend to need big test data sets. Adds too much inertia to code refactoring.

Thanks Sebbbi, this actually makes a lot of sense to me.


Sent from my iPhone using Tapatalk
 
Thanks Sebbbi, this actually makes a lot of sense to me.
Same applies to all your custom low level data structures, such as containers, linear algebra classes and threading primitives. As a game developer you need to write some of these yourself, as std ones are not cache optimized and do not use SSE/AVX. Writing and maintaining unit tests for core libraries like these is straightforward. Code inertia is not a problem, as code like this tends to change slowly and tends to have solid interfaces (interface practically never changes as there's huge amount of client code using it).
 
That's by far the hardest part about testing: doing it so that refactoring doesn't become a pain. I go for test-first development more and more, with a strong priority on unit tests using NSubstitute for mocking out stuff that is irrelevant to the test. And if I can't write a good, concise unit tests of a small part of the code, I tend to consider that a code smell - the code is doing to much with too many dependencies.

Biggest advantage for me with test-first approach is that you write tests first defining what your code needs to do, and then when you start writing your code you can test a) if the test fails before you wrote the code, b) if your new code works, c) if everything else still works, and d) do this much faster typically than by building and starting the whole application. This last part can be rather huge.

In my last project we had everything including all sorts of automated UI testing. It was so big with 24 active devs that it was pretty essential.

But sebbbi is also right that if you are not careful about setting your tests up right, every one hour of code refactoring can be x8 for fixing the test setups. Setting up your code and tests so that refactoring benefits more than suffers is an important art that I learnt a lot about partly by bad example recently. But I do have a lot of ideas about how to do it better.

And of course I don't always do tests first when I am still figuring out if something is even possible.
 
Back
Top