Are there specific techniques for testing 3D applications?

Question

Software testing

Hello!
I have only recently dealt with TDD and testing in general. While studying the theoretical aspects. Here are some, in my opinion, non-trivial questions. Colleagues, share your experience!
Question 1.
Suppose we are making a 3D mesh editor for a model. We have a test-covered function for combining meshes in the editor. But here's the annoyance: with some combinations of geometries and the relative position of models, the merging does not form the shape that the user expects to see. For example, when two spheres merge, in some cases, something very reminiscent of the Churyumov-Gerasimenko comet is obtained. In addition, there are polygons that are incorrectly oriented towards the observer.
Is there a way to programmatically detect such lags. Is there a way to write a test for "it"?
Question 2.
Imagine that we are designing a 3D game or demo. So far, we can only display the landscape, the sky with clouds, buildings, grass, trees, and some other static objects. Finally, we decided to introduce the concept of "wind" into our model of the world. So far, it's simple: you either have it or you don't. Only grass and trees will react to the wind: they will simply sway, imitating the very fact of the wind. Plus, the background sound of the wind appears in the world. The first stage has been completed.
Then we decided to parametrize the wind by adding strength and direction to it. Now the grass and trees bend away from the wind, and the amplitude of their oscillations depends on the strength of the wind. (We can say that the logical field "is or is not" for the wind has turned into a real "strength" of the wind. And the old isWindOn function now returns the result by checking: wind.force > 0). But imagine that after that, we began to lag the background sound accompaniment. When it appears and when it doesn't. What is the method to test the very fact of this in general in order to prevent it from happening in the future?
Well, or another probable problem with the sound: at very small values ​​of the wind force, grass and trees do not sway, but the sound still goes on. It turns out that there is noise from the wind, but there is no action. It is clear that the solution here is, at a minimum, to set the dependence of the volume of the background sound on the strength of the wind. But how (purely hypothetically) to write a test for the discrepancy between the volume of sound and the amplitude of vibrations of trees and grass? You never know: what if refactoring, or further "innovations"?
Or imagine that some trees in the process of deformation of the trunk (under the action of the wind) with some combination of the value of the wind force and their location on the ground, say, turn upside down. Moreover, it becomes noticeable only at a certain camera angle of the observer.Каким тестом отслеживать подобное? Ведь формально, модульные и функциональные тесты проходят. Они не могут выявить нарушение геометрии. Человеко-тестеры тоже не всегда могут выявить такое безобразие. А ну как в продакшн?
Ну или еще подобное. Скажем, выявилось проникнование части персонажей за преграду (например, рука сквозь стену). В общем факты этого отслеживается специальной логикой. Есть даже тесты, проверяющие работу модуля, контролирующего пересечение двух объектов в пространстве. Но каким образом гарантировать, что тест в принципе верный? Что если сам тест написан неверно, и его писатель, допустил ошибку при оценке множества выходных значений (заузил возможный диапазон)?

Answer 1

TDD работает если к задаче можно написать тест и с написание теста может справиться хотя бы джуниор-мидл. Как вы напишете тест к октодереву, освещению или шейдеру? Никак же. FPS, артефакты, корректное отображение входных данных и прочее. Можете держать 100500 мелких тестовых проектов для отладки. Пишите генератор ресурсов на питоне и скармливайте программе. Может в Юбисофтах и прочих ЕА всё более гибко за счет овер-експириенсных кадров.

Answer 2

1 случай - ну вообще то триада Хоара в чистом виде, у вас по входу набор вершин и по выходу тоже. Можно строить автоматизированные тесты по образцу.
2 ручное тестирование. Ну и опять же, амплитуда - это численная характеристика, наносите на террайн изомапу амплитуд звука, сравнивайте с эталонными.
3. Гарантировать корректность теста можно только если тест алгоритмически тривиален, очевидно. К счастью все тесты (почти все, скажем) - именно таковы.
Про тестирование шейдеров - я обычно вывожу в MRT какие то виузализации промежуточных вычислений, почти всегда можно придумать что-то такое. Читать нормализованные вектора в rgb все уже привыкли, если что :)