About the test, I wonder though what's with sf::Vector2u and sf::Vector2f?
Tank wrote the test for
Vector2i and it should generalize to
Vector2<T>, because there are no template specializations, so the type should behave the same.
There are of course cases where
int and
float behave differently, for example with division, floating precision (bigger floats are less precise in their decimal places), rounding errors and special values (NaN, infinity, ...). But I think for the idea of testing the
Vector2<T> functionality it's okay.
Test coverage is not 100% anyway, since we cover only one particular value per operation. Consider
SECTION("Comparison operations (two equal and one different vector)")
{
sf::Vector2i firstEqualVector(1, 5);
sf::Vector2i secondEqualVector(1, 5);
sf::Vector2i differentVector(6, 9);
SECTION("vector == vector")
{
CHECK(firstEqualVector == secondEqualVector);
CHECK_FALSE(firstEqualVector == differentVector);
}
SECTION("vector != vector")
{
CHECK(firstEqualVector != differentVector);
CHECK_FALSE(firstEqualVector != secondEqualVector);
}
}
The following
wrong implementation of
operator!= would still pass this test:
template <typename T>
bool operator!= (const sf::Vector2<T>& lhs, const sf::Vector2<T>& rhs)
{
return lhs.x != rhs.x;
}
Now, in my opinion we can be a bit pragmatic, especially for class templates like
sf::Vector2 that have existed for ages, been used by thousands of people, and are very unlikely to change in the future.
Regarding 1), I would add a tag to the test case (it can be as simple as the module being tested). This is nice if when working on something you want to run only a subset of tests.
Good idea.
Regarding 5), I guess we could duplicate some resources inside test/.
Should we really waste the space (e.g. for music or fonts, it can quickly be a few MB)? Is Git smart regarding exact file duplicates?
As for 6), I'd say we don't do it unless there's a bug and it's actually useful to have the output, unless someone really want to spent his time doing that 
.
Maybe one for the most fundamental types like vectors or rects are useful, but I don't think it makes sense to provide it for more complex classes like
sf::Sprite, either. After all, string conversions are only invoked in a relational comparison, an operation that most SFML classes don't even support.
