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

Groups > comp.lang.java.programmer > #37587 > unrolled thread

Eclipse question

Back to article view | Back to comp.lang.java.programmer

Contents

  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

#37587 — Eclipse question

On my toolbar is a green button with an arrow pointing right I use to run programs.
Next to that button is another green button with a green and red box under it the hover tip calls Launch.  If I use this button it runs a program, and after the program terminates it highlights every line it executed in green, and every line it didn't execute in red.  How do I clear these highlights?

[toc] | [next] | [standalone]

#37588

On Fri, 27 Oct 2017 05:32:59 -0700 (PDT), Eric Douglas wrote:

> On my toolbar is a green button with an arrow pointing right I use to run programs.
> Next to that button is another green button with a green and red box under it the hover tip calls Launch.  If I use this button it runs a program, and after the program terminates it highlights every line it executed in green, and every line it didn't execute in red.  How do I clear these highlights?

That is quite a bad sign - you found the code coverage aspect of Eclipse,
and it highlights lines that are not covered by any of your unit tests. If
you have a lot of red lines, that is indicative of bad or missing unit
tests ;-)

Getting rid of the highlights is weird, but not hard: after/during running,
a window should have appeared, by default in the area where you have the
console window and the problems view, called "Coverage". In there, you will
find additional coverage information, and on the right corner, a set of
icons allowing you to do other coverage-related tasks.

Two of those icons are a single X and two stacked Xs, and they remove the
the active coverage session or all coverage sessions, respectively.

Liebe Gruesse,
		Joerg

[toc] | [prev] | [next] | [standalone]

#37589

On Friday, October 27, 2017 at 9:29:15 AM UTC-4, Joerg Meier wrote:
> On Fri, 27 Oct 2017 05:32:59 -0700 (PDT), Eric Douglas wrote:
> 
> > On my toolbar is a green button with an arrow pointing right I use to run programs.
> > Next to that button is another green button with a green and red box under it the hover tip calls Launch.  If I use this button it runs a program, and after the program terminates it highlights every line it executed in green, and every line it didn't execute in red.  How do I clear these highlights?
> 
> That is quite a bad sign - you found the code coverage aspect of Eclipse,
> and it highlights lines that are not covered by any of your unit tests. If
> you have a lot of red lines, that is indicative of bad or missing unit
> tests ;-)
> 
> Getting rid of the highlights is weird, but not hard: after/during running,
> a window should have appeared, by default in the area where you have the
> console window and the problems view, called "Coverage". In there, you will
> find additional coverage information, and on the right corner, a set of
> icons allowing you to do other coverage-related tasks.
> 
> Two of those icons are a single X and two stacked Xs, and they remove the
> the active coverage session or all coverage sessions, respectively.
> 
> Liebe Gruesse,
> 		Joerg

ok, found the button "remove active session", or "remove all sessions" seems to do the trick.

Sometimes I just hit that launch by accident, otherwise I'm just trying to see one test run.  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.  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".

[toc] | [prev] | [next] | [standalone]

#37591

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

[toc] | [prev] | [next] | [standalone]

#37592

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       |

[toc] | [prev] | [next] | [standalone]

#37594

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

[toc] | [prev] | [next] | [standalone]

#37595

On Friday, October 27, 2017 at 2:08:26 PM UTC-4, Arne Vajhøj wrote:
> 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.
> 

Input-output is easy enough when my input is 2 and 6, my method is mutiply() and my result is 12.
How do you write a complete test when my input is end user, my method is "drag mouse from GUI control A to control B", and my result is "does the end model show what the user expects".

[toc] | [prev] | [next] | [standalone]

#37596

On 10/27/2017 2:23 PM, Eric Douglas wrote:
> On Friday, October 27, 2017 at 2:08:26 PM UTC-4, Arne Vajhøj wrote:
>> 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.
>>
> 
> Input-output is easy enough when my input is 2 and 6, my method is mutiply() and my result is 12.
> How do you write a complete test when my input is end user, my method is "drag mouse from GUI control A to control B", and my result is "does the end model show what the user expects".

     "I don't know."  Others have mentioned testing frameworks for
GUI's, but I'm unfamiliar with them and can't help you.

     However, you can at least write unit tests for the model: It
doesn't (or shouldn't) matter whether theModel.setWobbleRate(3.2)
is called from an ActionListener or from somewhere else -- like a
unit test, for example.  The unit test can then turn around and
check that the result of theModel.getWiggleSpan() is consistent
with the new wobble rate, or can check that the bad wobble rate
provokes an exception, or can check that changing the wobble rate
sends suitable events to the listeners the test itself registers.

     One benefit of separating the view and the model is that most
of the "business logic" resides in the latter, where it's easier to
test.  If the GUI consists mostly of sending data to the model and
getting notifications back from it, the GUI can be simpler and
(perhaps) less in need of this sort of testing.

-- 
esosman@comcast-dot-net.invalid
Eleven hundred eighty-one days to go.

[toc] | [prev] | [next] | [standalone]

#37600

On 10/27/2017 2:23 PM, Eric Douglas wrote:
> On Friday, October 27, 2017 at 2:08:26 PM UTC-4, Arne Vajhøj wrote:
>> 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.
> 
> Input-output is easy enough when my input is 2 and 6, my method is
> mutiply() and my result is 12.
> How do you write a complete test when my input is end user, my
> method is "drag mouse from GUI control A to control B", and my
> result is "does the end model show what the user expects".

Some just test the underlying logic and not the UI.

Some use special UI test frameworks to automate user
actions.

Arne

[toc] | [prev] | [next] | [standalone]

#37601

On Fri, 27 Oct 2017 11:23:10 -0700, Eric Douglas wrote:

> On Friday, October 27, 2017 at 2:08:26 PM UTC-4, Arne Vajhøj wrote:
>> 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.
>> 
>> 
> Input-output is easy enough when my input is 2 and 6, my method is
> mutiply() and my result is 12.
> How do you write a complete test when my input is end user, my method is
> "drag mouse from GUI control A to control B", and my result is "does the
> end model show what the user expects".

Add logging to capture GUI inputs to the model and messages passed to the 
view by the controller as two separate files that represent test input 
data and the corresponding expected results. 

Write a test harness that plays the logged inputs into the model and  
captures controller outputs. Add a module that compares captured output 
with a previously generated set of outputs that has been checked and 
passed as correct: this is the expected results set. Any differences 
between test output and the expected results is an exception that MUST be 
investigated and treated as a bug until proved otherwise.

Now you've got a regression test harness that can exercise everything 
except the view and so will most likely catch the majority of logic, 
validation and error reporting problems. This should be fairly easy to 
write and, since the application can log messages that are the direct 
result of user input, it should be easy to generate quite complex test 
inputs for incorporation in your regression test set.

With this type of setup you may not need a GUI tester, since data flows 
within the view module are generally pretty direct and faults are obvious 
and anyway the model and controller logging is grabbing all the viewer 
model inputs and outputs, so is just what you need to debug viewer 
problems.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web