Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Desktop or Web apps alike have the same testing pattern here (I've worked in both).</p> <p>Place as little logic as possible in the UI and test everything below it. So you say, but what if I want to test that such and such happens when a button is clicked? The method that is called when that button is clicked should call out to another class that actually does the thinking.</p> <p>You might say, but I'm using some static classes/methods that can only exist in my UI, wrap those with an adapter and utilize that interface in order to make your code testable.</p> <p>The parts of your GUI tests that you want to automate should be automated below the UI. There are parts of your GUI that you can't automate. Checking to make sure things "look right", or testing that you can see certain elements, etc. All of that is what your humans should be doing. Ensuring that events are properly firing, and that values are being appropriately returned from your business objects, that's all unit tests.</p> <p>I can see from your question that you've already pretty much decided you need an automated GUI tester, but that's not the right tool for this job. If you decide to use that you're trying to find the best way of doing the wrong thing.</p> <p>If you think that this isn't about unit testing because you're testing GUI interactions, then I can guarantee you're not unit testing close enough to your UI. If you were, you'd feel like most of what you'd be testing was redundant.</p> <p>If you disagree with me, please post some reasons and we'll hash this out.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload