Added a testCameraGraphical to eliminate the double-window thing - was happening because the test runner was trying to run as well as my IDE - I *think* that's what happens at least. It was bugging me really badly.
Tests are only good for what you're testing, they're not magic. Level functions taking (x, y) should NOT rely upon IndexError - if it *ends up on* the List it won't throw an IndexError, it'll just return an improper index! Because it's 2d, you see. Anyways. Rewrote the Level functions taking (x, y) to return properly. This fixed the error which was causing Camera._sprites to become overpopulated.
Forgot to add in drawing the cursor. Did so.
Level.set_cells is very volatile right now - it throws three different types of exceptions. If the level is already set, if the width of the incoming cells is incorrect, and if the height of the incoming cells is incorrect. Put in tests to make sure they get thrown; a cell width/predicted cell width mismatch is a HUGE error, probably caused by an incorrectly written level file. Also implemented the throwings.
Made a z_defs. DIR is the reference for an object which serves mostly as an enum. Also wrote test and tested Camera.step().
Whoops handle the bad input case for the z_defs. Handled.
So, the real issue with the pyglet.app.run() in a test is that if you have more than one test in the class, it messes up. I'm assuming this is because the pyglet.app.run() stores some sort of state independant to the test class, so when it tries to run another test, the state's still there and it bugs out and oh dear. As a band-aid (terrible) solution, I'm just making each graphical test I want to run its own class, because I'd rather keep going then spend hours and hours of time on the intricacies of pyglet and unittest and their interactions. I hope this doesn't come back to bite me.
Several things. Renamed graphical Camera tests, moved all the assets into an assets module. Now, when trying to load images, checks local, then assets, then defaults. I'll probably end up making an AssetLoader or somesuch if I have to write that snippet again, but right now that's how Cell and Camera get their images.
Flowcharted (I'm bad with Flowcharts I use them as notes, never actually 'learned' them) the way that the UI's going to work.
Was listing possible actions, but it's almost 5. End of day commit; current task - work on input into the UI.