How to test small classes?

Question

Unit testing

When another class is used inside one, then in the general case, the approach to testing is clear to me. An interface is created for the inner class and then dependency injection is used, when we substitute a specific implementation of this class when creating an outer one (through a constructor, through a setter, or something else). Then when testing, a stub or mock is created, depending on what is currently being tested, and simply substituted in place of this inner class.
But this is justified in cases with sufficiently large classes, but what if the inner class is too simple to create an interface for it?
Let's say I'm writing some kind of graphics engine, and I have a mesh class that represents a mesh of polygons. For simplicity, let's assume that the mesh does not store individual polygons, but simply an array of vertices, and when rendering, it is considered that every three consecutive vertices is one polygon. Each vertex is represented by its coordinates (stored in a vector - the Vector3D class).
The Mesh class needs to be tested - there, for example, there may be a getBoundingBox() method that calculates the box bounding the mesh. We need a test to control the correctness of such calculations.
But the same tests are needed for the Vector3D class! For example, it might have a cross() method that computes the cross product, which is non-trivial enough to test for.
It is unrealistic to use the Vector3DInterface interface in this case - there can be hundreds of thousands of vertices in the mesh, and then the very small overhead for calling virtual methods and storing the table of virtual functions will become very noticeable.
Instead of Vector3D, it is in the Mesh class that a simpler Point class with three public fields x, y, z and no methods is also not an option - in some other classes or in the methods of the Mesh class, it is the methods of the Vector3D class that may be required and each time create a Vector3D from them Point - the same brakes on hundreds of thousands of peaks.
If you just write tests for both Vector3D and Mesh, then you have to break the testing rule - do not be tied to the order of the tests. To test the inner class first and then the outer one.
Well, and, finally, this example is just an example, the question is not about this specific situation, but about the problem as a whole.
So how do you test a small inner class when dependency injection is not allowed?

Answer 1

Personally, I do not see a problem in this, only I would divide it into 3 parts
1) tests for the vector
2) tests for any mesh algorithms (the implementation of getBoundingBox itself must not be in the mesh). By the way, you can put the algorithms themselves into a separate interface and use dependency injection for mocking.
3) tests of the mesh itself.
In general, a vector class is not an object (in the sense of OOP) but an abstract data type (ATD). In C++, for example, it's quite important to understand what you mean by the class keyword.

Answer 2

You write a console application and run tests there. In parallel, write your decision on a piece of paper and check your answers. Write your assert. A vector and a matrix can, in operator ==, operator !=, display on the screen, and so on? Have a look at Google C++ Testing Framework.