Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #37592
| From | Martin Gregorie <martin@address-in-sig.invalid> |
|---|---|
| Newsgroups | comp.lang.java.programmer |
| Subject | Re: Eclipse question |
| Date | 2017-10-27 17:22 +0000 |
| Organization | A noiseless patient Spider |
| Message-ID | <osvq1b$t1b$2@dont-email.me> (permalink) |
| References | <051ea305-3fc8-4087-bd2a-bd4c7bd131c5@googlegroups.com> <14pdv8gcyixc2$.nrjypzl7wkp7.dlg@40tude.net> <a539e9c2-d3cf-4bf9-8a77-c78605ec1b3b@googlegroups.com> <osvgqo$1usm$1@gioia.aioe.org> |
On Fri, 27 Oct 2017 10:45:45 -0400, Arne Vajhøj wrote: > On 10/27/2017 9:41 AM, Eric Douglas wrote: >> This is not a JUnit test, I'm not trying >> to execute every line of code in my API. I don't even know much about >> JUnit, haven't written a test, am just developing an API where I have >> been the primary or sole developer. > > Maybe time to learn something new? > > :-) > >> I don't even know how one >> would write an automated test of a full API that would tell you things >> like "what does this custom JTable run through when I click this cell". > > UI code is not as easy to unit test as other layers. > > But just unit testing the underlying layers is still good. > > And there are some tools for unit testing UI's as well. > > Arne With the right tools to run unit tests and regression tests, the hard part is writing test data to test all aspects of a class including failure modes and error trapping. Ideally these should NOT be written by the programmer, and MUST be written from the specifications and/or class documentation without any reference to the code: i.e. you're should test the code against its specifications and not what the programmer thought they said. They the tests should be should be accompanied by expected results and ideally will automate comparisons of test results with expected results because doing that saves a lot of time and avoids making mistakes while doing it. The comparison may be as simple as running test results and actual results through the diff utility. If the comparison is quick and highlights differences thats a major incentive to rerun the tests each time the code is modified. Regression tests are good timesavers, so treat the test harness, test data and expected results with as much care and attention as the source code because rerunning the regression tests after any change, no matter how trivial, is always a good idea. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Eclipse question Eric Douglas <e.d.programmer@gmail.com> - 2017-10-27 05:32 -0700
Re: Eclipse question Joerg Meier <joergmmeier@arcor.de> - 2017-10-27 15:29 +0200
Re: Eclipse question Eric Douglas <e.d.programmer@gmail.com> - 2017-10-27 06:41 -0700
Re: Eclipse question Arne Vajhøj <arne@vajhoej.dk> - 2017-10-27 10:45 -0400
Re: Eclipse question Martin Gregorie <martin@address-in-sig.invalid> - 2017-10-27 17:22 +0000
Re: Eclipse question Arne Vajhøj <arne@vajhoej.dk> - 2017-10-27 14:08 -0400
Re: Eclipse question Eric Douglas <e.d.programmer@gmail.com> - 2017-10-27 11:23 -0700
Re: Eclipse question Eric Sosman <esosman@comcast-dot-net.invalid> - 2017-10-27 15:10 -0400
Re: Eclipse question Arne Vajhøj <arne@vajhoej.dk> - 2017-10-27 19:05 -0400
Re: Eclipse question Martin Gregorie <martin@address-in-sig.invalid> - 2017-10-27 23:44 +0000
csiph-web