4 ms·

Great! Now how do you TDD KDE UI code?

• sethrin 14y ago
  I am not entirely sure, but I think you GDB the STDOUT, grep the bin, and if that doesn't work, reroute the auxiliary phase array to the main deflectors. It works every time. I'm going to go out on a limb and say that if you write KDE UI code, you should be able to answer the question of how to test it, preferably in the automated sense. Notwithstanding all argument for and against TDD, the best proof of correctness is a long (manual) testing cycle.
  • pjmlp 14y ago
    The thing is, there is yet to exist any tool that allows TDD of desktop UIs beyond the toy examples people come up with web applications at conferences.
• lmm 14y ago
  The same way. KDE components are very modular, so it's trivial to write a UI form that displays a bunch of components from various parts of your code. You could write a second executable that just displays this test form with test data (most of your code should be written as a library anyway, so having two executables that call your components shouldn't be an issue). Of course more automation is better, so I'd probably want to write a selenium-equivalent for asserting things about a component tree. Again, the KDE components are very regular so it's easy to generically traverse/inspect a GUI. It's really not hard if you actually try.