Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #37594

Re: Eclipse question

Show all headers | View raw

On 10/27/2017 1:22 PM, Martin Gregorie wrote:
> 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.
> 
> 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.

It is a huge task to write really complete tests.

But my take on that is that non-complete tests are better than no
tests.

You write unit tests for what is possible in the given project context.
And you enjoy the benefits of the tests that were written.

The fact that it would have been possible to write 10 times more
tests is not a good argument for not writing any tests.

No - I don't think you suggested that.

>                                    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.

Or write the tests first as part of the design.

:-)

> 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.

Most unit test frameworks make that rather easy.

> 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.

Yes.

Arne

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

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