Quote:
and yup, you should have a test that mocks out fake poker windows and moves them around, and then confirms they moved the correct location. but thats later, first thing you need to do is breaking your code into small and testable pieces.
If the code is already written as a big mess - you probably don't want to refactor before getting test coverage in place. Or at the very least, you'll want to do it at the same time. So pick a function to refactor, write tests for it, make small changes, run tests, and keep doing that until you get nice code that is also unit tested.
As for the fake poker windows - I wouldn't worry about that. Start by pulling out any logic and writing functions that implement that logic without needing to know about UI concerns. So for example if you have a function that moves some GUI element to some coordinate on the screen break that into two functions - one to calculate the new co-ordinates and one really generic function that just moves the element to those coordinates.
This allows you to easily test the logic without worrying about UI concerns.
Testing the UI itself can be a big pain and I think people often go overboard trying to automate it - which just ends up as a big headache.