Do everything in Java…

H. S. Teoh via Digitalmars-d digitalmars-d at puremagic.com
Sat Dec 6 07:24:19 PST 2014


On Sat, Dec 06, 2014 at 03:09:21PM +0000, Russel Winder via Digitalmars-d wrote:
> 
> On Fri, 2014-12-05 at 12:44 -0800, Walter Bright via Digitalmars-d wrote:
> > On 12/5/2014 5:41 AM, H. S. Teoh via Digitalmars-d wrote:
> > > As for GUI code, I've always been of the opinion that it should be
> > > coded in such a way as to be fully scriptable. GUI's that can only
> > > operate when given real user input has failed from the start IMO,
> > > because not being scriptable also means it's non-automatable
> > > (crippled, in my book), but more importantly, it's not auto-
> > > testable; you have to hire humans to sit all day repeating the
> > > same sequence of mouse clicks just to make sure the latest dev
> > > build is still working properly. That's grossly inefficient and a
> > > waste of money spent hiring the employee.
> 
> You actually need both. Scripting end-to-end tests, systems tests,
> etc. is important but most systems also needs humans to try things
> out.

Oh, certainly I'm not expecting *all* tests to be automated -- there are
some things that are fundamentally non-automatable, like testing
look-and-feel, user experience, new feature evaluation, etc.. My
complaint was that the lack of automation has caused QA to be completely
occupied with menial, repetitive tasks (like navigate the same set of
menus 100 times a day to test 100 developer images, just to make sure it
still works as expected), that no resources are left for doing more
consequential work. Instead, things have gone the opposite direction --
QA is hiring more people because the current staff can no longer keep up
with the sheer amount of menial repetitive testing they have to do.

If these automatable tests were actually automated, the QA department
would have many resources freed up for doing other important work --
like testing more edge cases for potential problematic areas, etc..


> > A complementary approach is to have the UI code call "semantic"
> > routines that are in non-UI code, and those semantic routines do all
> > the semantic work. That minimizes the UI code, and hence the testing
> > problem.
> 
> The usual model is that GUI code only has GUI code and uses a Mediator
> and/or Façade to access any other code. Similarly separate business
> rules from database access (DAO, etc.). Separation of Concerns, Three
> Tier Model, MVC, MVP, there are masses of labels for the fundamental
> architecture, but it is all about modularization and testability.
> 
> > Most GUI apps I've seen mixed up all that code together.
> 
> You haven't seen many then :-), and most of them have been crap and
> should have had the incantation "rm -rf *" applied.
[...]

Unfortunately, I suspect that if I adopted that policy, I'd have to nuke
most of my OS. :-P


T

-- 
Knowledge is that area of ignorance that we arrange and classify. -- Ambrose Bierce


More information about the Digitalmars-d mailing list