A lot of people seem to think graphics are impervious to traditional TDD/unittesting. This isn't true.
The issues surrounding TDD are that the images won't always be exactly the same. Things like antialiasing settings (which can be overridden by driver settings). Differences between how different GPUs render the same image (polygon unwinding orders and such). Also as your game goes through development things like meshes and textures might get changed or tweaked.
Also people think you often need to do it and eyeball the result prior to seeing if its ok then add it as a passing test case (which will break due to the above issues).
You could wrap all the OpenGL calls with logging ones and ensure that things are called as expected, but that doesn't test the graphics are actually valid it just tests that your program is making the calls you predict that it should make. That's not very useful and it will be quite a bit of work. Also it's going to be hard to maintain if you do things like optimize out unnecessary draw calls.
What I would recommend doing is decoupling your rendering output from your windowing system. What I mean by that is 'Render to Texture' or use FrameBuffer Objects. This also helps with do things like viewports and UI/HUD overlays.
Make a 'Window' object. Something that opens an actual desktop Window using Qt, SDL, SFML, GLUT, or whatever. And pass in some kind of a Renderer to it. You can do things like allow multiple renderers and specify rectangle coordinates (you could render a different view in the corner of the screen). Or maybe make one master renderer but inherit a version that allows it to have subrenderers. The Window object can also handle the input, this provides a nice way to inject a fake/mock input object, you can test if the player moves forward as expected.
This modular approach is the kind of thing that falls out of TDD, it could also could let your renderer have its own renderers (maybe you want to do a skybox separately, or a picture on a security monitor in a game, reflections, shadowmaps and so on). You can also easily render at a different resolution to the native desktop (which is useful for setting a fixed resolution in TDD and could just be something like 32x32 for simple operations, but is also useful for devices like Android where the resolutions are fixed and the GPUs have different capabilities. Nexus 10 not beefy enough to render your game at its XDPI? Scale it down. Also helps with Linux/Xorg which doesn't always allow you to set all resolutions the GPU does although thats less of a problem now days).
Once you have your FBO, make some functions to query pixel colour. Then you can query all your basic operations. Do your meshes render correctly? Test it. Make a mesh with a single white triangle and query which positions you would expect to see white and which should remain black when drawing that triangle. A 1x1 triangle in a 1x1 window should cover %50 diagonally so test pixels near the edge and both sides of the middle, the borders of the window and the pointy bits. Next combine two triangles into a rectangle and it should fill the screen, now all the pixels should be white. Now try moving it away from the camera and check that the borders are black but the centre is white, with a 1.0x1.0 rectangle in a 1.0x1.0 window at 1.0 away you can apply some simple geometry to see approximately where the borders should end. Test with a different color. Make a more complex mesh with a multicolored cube and test rotation. Make a test normal map.
You might be able to test lights by rendering a sphere and and checking that the left side it brighter than the right and if you add another light on the other side they are about the same (just add all the pixels on the left and all the pixels on the right and compare within a margin of error). Increase the light brightness and see if the sum of the pixels goes up. You can test the lighting algorithms by working out the expected color at a specific point on a flat plane.
You could see that spectral highlighting is brightest at the expected area. For your normal/bump mapping make a test texture.
Just avoid anything really specific, for example don't test exactly on an edge. They could be antialiased or just off slightly. If your doing something like testing the left/right brightness for lighting, don't expect the pixel count to be the same number on different systems or even both sides (in a symmetrical scene), use an error margin. Don't use real data, make sure you use basic 'test' textures and meshes that won't change.
