>>883890 (OP)
>Как блея проверять бустом что рисуется или не рисуется?
О, это извечная боль для разработчиков графических приложений которые что-то рендерят. Как проверить результат отрисовки?

Я когда работал над 3д движком делал вот так:

1) Находишь метод для рендера в текстуру. Не помню уже что за glut (это же вроде какое-то устарелое говно мамонта, или я путаю?), но вообще такой должен быть.

2) Создаешь набор тестовых сцен (хуй знает что у тебя за проект, но в случае с 3д движком набор будет в духе "пара кубиков", "шарик с шейдером", "кубик под лампочкой", "система партиклей" и т.п.)

3) Для каждой сцены рендеришь референсные скриншоты (можно по несколько на сцену, например с разных ракурсов), сохраняешь их.

4) Пишешь тесты в духе "загрузить сцену -> отрендерить в текстуру -> сравнить результат с загруженной с диска референсной картинкой".

Сравнивать очевидно стоит не точным сравнением, а с некоторой дельтой, с учетом возможных небольших несовпадений (в пределах пары пикселов) из-за всяких погрешностей. Я для такого когда-то использовал Perceptual Diff тулзу.

Профит.

Наличие таких тестов впрочем не исключает необходимость в обычных юнит-тестах. Так как несовпадение скриншотов конечно сообщит тебе о проблеме, но ее будет достаточно сложно локализовать.

Если у тебя проект уже готовый, к которому ты решил прикрутить тестирование, то с высокой вероятностью его код для тестирования плохо подходит (сильная связность компонент, необходимость воспроизводить сложное внутреннее состояние для каждого тестового вызова и т.п.), но тут уж ничего не поделаешь, либо рефакторь, либо отказывайся от тестов.