Unit tests

[Hiura]

@Tank: I'm just wondering if some of us -- probably you in fact -- have more experience with techniques involving mock objects and could help defining a good strategy for tests.

I did some TDD a few years back for some Android app (a class project) but tbh I didn't like it. Although it was most probably because we were not properly taught how to do it.

[Tank]

I've done some work on such things, yeah. Not much with C++, but I guess there are always ways. I could work something out I guess. Any idea for a concrete code location? Maybe window creation code or something?

[eXpl0it3r]

Now that my PC is currently building SFML including the unit test branch, I noticed an issue that I had as well back when working with FlexWorld.

If you build the unittest application with SFML linked shared and then try to run it, the unittest, won't know where the shared libraries are and will simply crash.
It's essentially useless when we allow running the test directly after building SFML shared.

Question is, do simply prevent the unittests from running with shared libraries or do we copy things around in the build directory so the sfmltest application will actually find the proper libraries?

[Tank]

At least on Linux, the RPATH takes care of it, so that libraries don't have to be copied. Instead the full path to the libs is stored in the ELF file. I don't know how it works on Windows, though. If it's an issue, copying should work.

do simply prevent the unittests from running with shared libraries

That's simple indeed, but misses the point of unit testing.

[eXpl0it3r]

So anyone willing to update the branch, address the issue of shared libraries and create a PR?

[eXpl0it3r]

I just move this topic from internal discussions years ago into the public "SFML development" sub-forum, as the foundation for unit testing as discussed and implemented in this thread, will finally be merged in SFML 2.6.0.

See also the SFML Test Strategy thread.