Home » Eclipse Projects » Rich Client Platform (RCP) » unit testing vs. integration testing practices
|
| Re: unit testing vs. integration testing practices [message #452797 is a reply to message #452794] |
Sat, 15 July 2006 07:49   |
 Mike Evans
Messages: 237
Registered: July 2009 |
Senior Member |
|
|
On Fri, 14 Jul 2006 23:46:27 -0400, John Sanda wrote:
> I am working on an RCP project and in the process of researching options
> for testing code in the RCP layer of the application. I have spent a
> good bit of time over the past couple days reading threads from this
> newsgroup and from the swt newsgroup on testing UI code.
>
> As an aside, I am going to the book store to buy "Contributing to
> Eclipse" tomorrow. I am very eager to read it.
>
> I have come across numerous discussions on unit testing that involve
> starting up the workbench or initializing an entire plugin. These kinds
> of tests are not unit tests. They are integration tests. The motivation
> of a unit test is to test a piece of code in isolation from its
> dependencies at a very granular level. I think the distinction between
> unit tests and integration tests sometimes gets blurred because we use
> the same APIs to write both. Both types of tests are important and are
> essential testing tools.
>
> I apologize if I sound like I am on a rant...I'm not. I just want to
> make it clear what I am trying to accomplish. In my RPC project, I want
> to start developing unit tests. For example, lets say I have a
> perspective with a view that display my custom composite, MyComposite.
>
> I want to write some unit tests for MyComposite. Are there any reasons
> why I cannot or should not do something like the following?
>
> public class MyCompositeTest extends TestCase {
> private Shell shell;
>
> protected void setUp() throws Exception {
> shell = new Shell();
> }
>
> protected void tearDown() throws Exception {
> shell.close();
> shell.dispose();
> }
>
> public void testMyComposite() {
> MyComposite composite = new MyComposite(shell);
> // test behavior of MyComposite...
> }
> }
>
> MyComposite will obviously have dependencies on SWT classes and probably
> JFace classes. When and where possible I would mock those dependencies
> so that I could test exactly what I want in isolation. Is this a
> reasonable approach?
>
> Thanks and I am definitely learning a lot from these newsgroups!
I understand your distinction between unit and integration testing, but in
this age of agile development may I be a little heretical and suggest that
unit tests as you suggest might not be worth it?
I tried a similiar 'white box' testing framework to what I think you are
suggesting and realised early that to be in any way useful it would have to
emulate most of the platform behaviour anyway. The principle reason for
this was that the core of my GUI are (unsurprisingly) Views, Editors &
JFace Viewers. Their lifecycles and interactions (and hence much of
testable GUI bahviour) are intimiately bound to the platform and each
other. Hence in the end I was spending all my time debuggin my emulation
rather than any useful code.
My hand-rolled solution was to build a JUnit framework INTO my app so that
whne it runs up it can then self-test. Of course now there is the TPTP
project that might offer something much better (have not yet looked). I
believe there is also some commercial add-ons (somewhere) that offer a SWT
or JFace testing framework.
Hope this helps,
--
Mike E.
|
|
|
| Re: unit testing vs. integration testing practices [message #452799 is a reply to message #452797] |
Sat, 15 July 2006 13:26 |
John Sanda
Messages: 22
Registered: July 2009 |
Junior Member |
|
|
Mike Evans wrote:
> On Fri, 14 Jul 2006 23:46:27 -0400, John Sanda wrote:
>
>> I am working on an RCP project and in the process of researching options
>> for testing code in the RCP layer of the application. I have spent a
>> good bit of time over the past couple days reading threads from this
>> newsgroup and from the swt newsgroup on testing UI code.
>>
>> As an aside, I am going to the book store to buy "Contributing to
>> Eclipse" tomorrow. I am very eager to read it.
>>
>> I have come across numerous discussions on unit testing that involve
>> starting up the workbench or initializing an entire plugin. These kinds
>> of tests are not unit tests. They are integration tests. The motivation
>> of a unit test is to test a piece of code in isolation from its
>> dependencies at a very granular level. I think the distinction between
>> unit tests and integration tests sometimes gets blurred because we use
>> the same APIs to write both. Both types of tests are important and are
>> essential testing tools.
>>
>> I apologize if I sound like I am on a rant...I'm not. I just want to
>> make it clear what I am trying to accomplish. In my RPC project, I want
>> to start developing unit tests. For example, lets say I have a
>> perspective with a view that display my custom composite, MyComposite.
>>
>> I want to write some unit tests for MyComposite. Are there any reasons
>> why I cannot or should not do something like the following?
>>
>> public class MyCompositeTest extends TestCase {
>> private Shell shell;
>>
>> protected void setUp() throws Exception {
>> shell = new Shell();
>> }
>>
>> protected void tearDown() throws Exception {
>> shell.close();
>> shell.dispose();
>> }
>>
>> public void testMyComposite() {
>> MyComposite composite = new MyComposite(shell);
>> // test behavior of MyComposite...
>> }
>> }
>>
>> MyComposite will obviously have dependencies on SWT classes and probably
>> JFace classes. When and where possible I would mock those dependencies
>> so that I could test exactly what I want in isolation. Is this a
>> reasonable approach?
>>
>> Thanks and I am definitely learning a lot from these newsgroups!
>
> I understand your distinction between unit and integration testing, but in
> this age of agile development may I be a little heretical and suggest that
> unit tests as you suggest might not be worth it?
>
> I tried a similiar 'white box' testing framework to what I think you are
> suggesting and realised early that to be in any way useful it would have to
> emulate most of the platform behaviour anyway. The principle reason for
> this was that the core of my GUI are (unsurprisingly) Views, Editors &
> JFace Viewers. Their lifecycles and interactions (and hence much of
> testable GUI bahviour) are intimiately bound to the platform and each
> other. Hence in the end I was spending all my time debuggin my emulation
> rather than any useful code.
>
> My hand-rolled solution was to build a JUnit framework INTO my app so that
> whne it runs up it can then self-test. Of course now there is the TPTP
> project that might offer something much better (have not yet looked). I
> believe there is also some commercial add-ons (somewhere) that offer a SWT
> or JFace testing framework.
>
> Hope this helps,
>
>
Hey Mike,
Thanks for the feedback. What you are saying makes perfect sense. The
RCP code base with which I am working suffers from design that
deteoriated as the code base evolved. It is not all uncommon to find
classes that are 1000+ lines that are a dumping ground for presentation,
business, and controller logic. And there are zero tests in place -
unit, integration or otherwise. I have been assigned the task of coming
up with some steps and indentifying best practices. Getting some kind of
testing infrastructure is at the top of my list.
I think (hope) that some getting some unit tests in place will help me
get the code untangled. While I don't have a lot of Eclipse RCP
experience, I imagine that once there is better separation concerns, my
presentation/UI classes will deal with a couple things - presentation
logic and collaboration with other components. In that scenario, I don't
think I would reap much benefit out of unit testing. Mocking
collaboraion between table, table viewer, content provider for example,
seems to be somewhat pointless.
Clearly, I need both kinds of tests in place. I may need to spend some
time looking at TPTP or Abbott for SWT.
|
|
|
| Re: unit testing vs. integration testing practices [message #452815 is a reply to message #452799] |
Mon, 17 July 2006 08:42 |
Mike Evans
Messages: 237
Registered: July 2009 |
Senior Member |
|
|
On Sat, 15 Jul 2006 09:26:59 -0400, John Sanda wrote:
> Mike Evans wrote:
>> On Fri, 14 Jul 2006 23:46:27 -0400, John Sanda wrote:
>>
>>> I am working on an RCP project and in the process of researching options
>>> for testing code in the RCP layer of the application. I have spent a
>>> good bit of time over the past couple days reading threads from this
>>> newsgroup and from the swt newsgroup on testing UI code.
>>>
>>> As an aside, I am going to the book store to buy "Contributing to
>>> Eclipse" tomorrow. I am very eager to read it.
>>>
>>> I have come across numerous discussions on unit testing that involve
>>> starting up the workbench or initializing an entire plugin. These kinds
>>> of tests are not unit tests. They are integration tests. The motivation
>>> of a unit test is to test a piece of code in isolation from its
>>> dependencies at a very granular level. I think the distinction between
>>> unit tests and integration tests sometimes gets blurred because we use
>>> the same APIs to write both. Both types of tests are important and are
>>> essential testing tools.
>>>
>>> I apologize if I sound like I am on a rant...I'm not. I just want to
>>> make it clear what I am trying to accomplish. In my RPC project, I want
>>> to start developing unit tests. For example, lets say I have a
>>> perspective with a view that display my custom composite, MyComposite.
>>>
>>> I want to write some unit tests for MyComposite. Are there any reasons
>>> why I cannot or should not do something like the following?
>>>
>>> public class MyCompositeTest extends TestCase {
>>> private Shell shell;
>>>
>>> protected void setUp() throws Exception {
>>> shell = new Shell();
>>> }
>>>
>>> protected void tearDown() throws Exception {
>>> shell.close();
>>> shell.dispose();
>>> }
>>>
>>> public void testMyComposite() {
>>> MyComposite composite = new MyComposite(shell);
>>> // test behavior of MyComposite...
>>> }
>>> }
>>>
>>> MyComposite will obviously have dependencies on SWT classes and probably
>>> JFace classes. When and where possible I would mock those dependencies
>>> so that I could test exactly what I want in isolation. Is this a
>>> reasonable approach?
>>>
>>> Thanks and I am definitely learning a lot from these newsgroups!
>>
>> I understand your distinction between unit and integration testing, but in
>> this age of agile development may I be a little heretical and suggest that
>> unit tests as you suggest might not be worth it?
>>
>> I tried a similiar 'white box' testing framework to what I think you are
>> suggesting and realised early that to be in any way useful it would have to
>> emulate most of the platform behaviour anyway. The principle reason for
>> this was that the core of my GUI are (unsurprisingly) Views, Editors &
>> JFace Viewers. Their lifecycles and interactions (and hence much of
>> testable GUI bahviour) are intimiately bound to the platform and each
>> other. Hence in the end I was spending all my time debuggin my emulation
>> rather than any useful code.
>>
>> My hand-rolled solution was to build a JUnit framework INTO my app so that
>> whne it runs up it can then self-test. Of course now there is the TPTP
>> project that might offer something much better (have not yet looked). I
>> believe there is also some commercial add-ons (somewhere) that offer a SWT
>> or JFace testing framework.
>>
>> Hope this helps,
>>
>>
> Hey Mike,
>
> Thanks for the feedback. What you are saying makes perfect sense. The
> RCP code base with which I am working suffers from design that
> deteoriated as the code base evolved. It is not all uncommon to find
> classes that are 1000+ lines that are a dumping ground for presentation,
> business, and controller logic. And there are zero tests in place -
> unit, integration or otherwise. I have been assigned the task of coming
> up with some steps and indentifying best practices. Getting some kind of
> testing infrastructure is at the top of my list.
>
>
> I think (hope) that some getting some unit tests in place will help me
> get the code untangled. While I don't have a lot of Eclipse RCP
> experience, I imagine that once there is better separation concerns, my
> presentation/UI classes will deal with a couple things - presentation
> logic and collaboration with other components. In that scenario, I don't
> think I would reap much benefit out of unit testing. Mocking
> collaboraion between table, table viewer, content provider for example,
> seems to be somewhat pointless.
>
> Clearly, I need both kinds of tests in place. I may need to spend some
> time looking at TPTP or Abbott for SWT.
John,
Might I make one more (heretical) suggestion.
It sounds like you're dealing with the 'Big Ball of Mud' pattern
(http://www.laputan.org/mud/)! However you have one thing on your side -
you're dealing with client-side rather than server-side code. So, unless
the previous 'architects' used the Jobs framework or their own hand-rolled
async tasks, you probably have an effective single-threaded app. This is a
great advantage as you have far fewer states to consider. My approach to a
similar task I had once was to use (and here comes the heresy) ...
singletons. In broad terms I attempted to pull out all the
non-presentational stuff into a model and a controller singleton. Then I
could pull out all the stuff that was just being passed around to provide
references and what was actually used. Once I could start to see the wood
from the trees life became much simpler. And once I had a singleton it was
not long before this became an instance on my plug-in
MyPlugin.getDefault().getModel() and not long after this I started to have
a decent-looking RCP app.
Well - it's one idea.
Good luck!
Mike E.
|
|
|
| Re: unit testing vs. integration testing practices [message #453131 is a reply to message #452815] |
Sun, 23 July 2006 01:41 |
John Sanda
Messages: 22
Registered: July 2009 |
Junior Member |
|
|
Mike Evans wrote:
> On Sat, 15 Jul 2006 09:26:59 -0400, John Sanda wrote:
>
>> Mike Evans wrote:
>>> On Fri, 14 Jul 2006 23:46:27 -0400, John Sanda wrote:
>>>
>>>> I am working on an RCP project and in the process of researching options
>>>> for testing code in the RCP layer of the application. I have spent a
>>>> good bit of time over the past couple days reading threads from this
>>>> newsgroup and from the swt newsgroup on testing UI code.
>>>>
>>>> As an aside, I am going to the book store to buy "Contributing to
>>>> Eclipse" tomorrow. I am very eager to read it.
>>>>
>>>> I have come across numerous discussions on unit testing that involve
>>>> starting up the workbench or initializing an entire plugin. These kinds
>>>> of tests are not unit tests. They are integration tests. The motivation
>>>> of a unit test is to test a piece of code in isolation from its
>>>> dependencies at a very granular level. I think the distinction between
>>>> unit tests and integration tests sometimes gets blurred because we use
>>>> the same APIs to write both. Both types of tests are important and are
>>>> essential testing tools.
>>>>
>>>> I apologize if I sound like I am on a rant...I'm not. I just want to
>>>> make it clear what I am trying to accomplish. In my RPC project, I want
>>>> to start developing unit tests. For example, lets say I have a
>>>> perspective with a view that display my custom composite, MyComposite.
>>>>
>>>> I want to write some unit tests for MyComposite. Are there any reasons
>>>> why I cannot or should not do something like the following?
>>>>
>>>> public class MyCompositeTest extends TestCase {
>>>> private Shell shell;
>>>>
>>>> protected void setUp() throws Exception {
>>>> shell = new Shell();
>>>> }
>>>>
>>>> protected void tearDown() throws Exception {
>>>> shell.close();
>>>> shell.dispose();
>>>> }
>>>>
>>>> public void testMyComposite() {
>>>> MyComposite composite = new MyComposite(shell);
>>>> // test behavior of MyComposite...
>>>> }
>>>> }
>>>>
>>>> MyComposite will obviously have dependencies on SWT classes and probably
>>>> JFace classes. When and where possible I would mock those dependencies
>>>> so that I could test exactly what I want in isolation. Is this a
>>>> reasonable approach?
>>>>
>>>> Thanks and I am definitely learning a lot from these newsgroups!
>>> I understand your distinction between unit and integration testing, but in
>>> this age of agile development may I be a little heretical and suggest that
>>> unit tests as you suggest might not be worth it?
>>>
>>> I tried a similiar 'white box' testing framework to what I think you are
>>> suggesting and realised early that to be in any way useful it would have to
>>> emulate most of the platform behaviour anyway. The principle reason for
>>> this was that the core of my GUI are (unsurprisingly) Views, Editors &
>>> JFace Viewers. Their lifecycles and interactions (and hence much of
>>> testable GUI bahviour) are intimiately bound to the platform and each
>>> other. Hence in the end I was spending all my time debuggin my emulation
>>> rather than any useful code.
>>>
>>> My hand-rolled solution was to build a JUnit framework INTO my app so that
>>> whne it runs up it can then self-test. Of course now there is the TPTP
>>> project that might offer something much better (have not yet looked). I
>>> believe there is also some commercial add-ons (somewhere) that offer a SWT
>>> or JFace testing framework.
>>>
>>> Hope this helps,
>>>
>>>
>> Hey Mike,
>>
>> Thanks for the feedback. What you are saying makes perfect sense. The
>> RCP code base with which I am working suffers from design that
>> deteoriated as the code base evolved. It is not all uncommon to find
>> classes that are 1000+ lines that are a dumping ground for presentation,
>> business, and controller logic. And there are zero tests in place -
>> unit, integration or otherwise. I have been assigned the task of coming
>> up with some steps and indentifying best practices. Getting some kind of
>> testing infrastructure is at the top of my list.
>>
>>
>> I think (hope) that some getting some unit tests in place will help me
>> get the code untangled. While I don't have a lot of Eclipse RCP
>> experience, I imagine that once there is better separation concerns, my
>> presentation/UI classes will deal with a couple things - presentation
>> logic and collaboration with other components. In that scenario, I don't
>> think I would reap much benefit out of unit testing. Mocking
>> collaboraion between table, table viewer, content provider for example,
>> seems to be somewhat pointless.
>>
>> Clearly, I need both kinds of tests in place. I may need to spend some
>> time looking at TPTP or Abbott for SWT.
>
> John,
> Might I make one more (heretical) suggestion.
> It sounds like you're dealing with the 'Big Ball of Mud' pattern
> (http://www.laputan.org/mud/)! However you have one thing on your side -
> you're dealing with client-side rather than server-side code. So, unless
> the previous 'architects' used the Jobs framework or their own hand-rolled
> async tasks, you probably have an effective single-threaded app. This is a
> great advantage as you have far fewer states to consider. My approach to a
> similar task I had once was to use (and here comes the heresy) ...
> singletons. In broad terms I attempted to pull out all the
> non-presentational stuff into a model and a controller singleton. Then I
> could pull out all the stuff that was just being passed around to provide
> references and what was actually used. Once I could start to see the wood
> from the trees life became much simpler. And once I had a singleton it was
> not long before this became an instance on my plug-in
> MyPlugin.getDefault().getModel() and not long after this I started to have
> a decent-looking RCP app.
> Well - it's one idea.
> Good luck!
>
> Mike E.
Hey Mike. Just got back from vacation. You are quite the heretic! :-)
Actually, not too long ago, Spring and Hibernate were introduced into
the code base. As part of my assignment, I need to figure out how best
to integrate Spring into the RCP code.
I picked up copies of "Contributing to Eclipse" and "Eclipse Building
Commerical Quality Plug-ins". I have started reading the latter and
have already reached the conclusion that designing the app as a set of
small, (possibly) resuable plug-ins is the way to go. Currently, the
application consists of one giant monolithic plug-in. I will spend some
time searching for threads on this topic, and I may post some questions
as well.
Thanks again!
|
|
|
| Re: unit testing vs. integration testing practices [message #453132 is a reply to message #452815] |
Sun, 23 July 2006 01:45 |
John Sanda
Messages: 22
Registered: July 2009 |
Junior Member |
|
|
Mike Evans wrote:
> On Sat, 15 Jul 2006 09:26:59 -0400, John Sanda wrote:
>
>> Mike Evans wrote:
>>> On Fri, 14 Jul 2006 23:46:27 -0400, John Sanda wrote:
>>>
>>>> I am working on an RCP project and in the process of researching options
>>>> for testing code in the RCP layer of the application. I have spent a
>>>> good bit of time over the past couple days reading threads from this
>>>> newsgroup and from the swt newsgroup on testing UI code.
>>>>
>>>> As an aside, I am going to the book store to buy "Contributing to
>>>> Eclipse" tomorrow. I am very eager to read it.
>>>>
>>>> I have come across numerous discussions on unit testing that involve
>>>> starting up the workbench or initializing an entire plugin. These kinds
>>>> of tests are not unit tests. They are integration tests. The motivation
>>>> of a unit test is to test a piece of code in isolation from its
>>>> dependencies at a very granular level. I think the distinction between
>>>> unit tests and integration tests sometimes gets blurred because we use
>>>> the same APIs to write both. Both types of tests are important and are
>>>> essential testing tools.
>>>>
>>>> I apologize if I sound like I am on a rant...I'm not. I just want to
>>>> make it clear what I am trying to accomplish. In my RPC project, I want
>>>> to start developing unit tests. For example, lets say I have a
>>>> perspective with a view that display my custom composite, MyComposite.
>>>>
>>>> I want to write some unit tests for MyComposite. Are there any reasons
>>>> why I cannot or should not do something like the following?
>>>>
>>>> public class MyCompositeTest extends TestCase {
>>>> private Shell shell;
>>>>
>>>> protected void setUp() throws Exception {
>>>> shell = new Shell();
>>>> }
>>>>
>>>> protected void tearDown() throws Exception {
>>>> shell.close();
>>>> shell.dispose();
>>>> }
>>>>
>>>> public void testMyComposite() {
>>>> MyComposite composite = new MyComposite(shell);
>>>> // test behavior of MyComposite...
>>>> }
>>>> }
>>>>
>>>> MyComposite will obviously have dependencies on SWT classes and probably
>>>> JFace classes. When and where possible I would mock those dependencies
>>>> so that I could test exactly what I want in isolation. Is this a
>>>> reasonable approach?
>>>>
>>>> Thanks and I am definitely learning a lot from these newsgroups!
>>> I understand your distinction between unit and integration testing, but in
>>> this age of agile development may I be a little heretical and suggest that
>>> unit tests as you suggest might not be worth it?
>>>
>>> I tried a similiar 'white box' testing framework to what I think you are
>>> suggesting and realised early that to be in any way useful it would have to
>>> emulate most of the platform behaviour anyway. The principle reason for
>>> this was that the core of my GUI are (unsurprisingly) Views, Editors &
>>> JFace Viewers. Their lifecycles and interactions (and hence much of
>>> testable GUI bahviour) are intimiately bound to the platform and each
>>> other. Hence in the end I was spending all my time debuggin my emulation
>>> rather than any useful code.
>>>
>>> My hand-rolled solution was to build a JUnit framework INTO my app so that
>>> whne it runs up it can then self-test. Of course now there is the TPTP
>>> project that might offer something much better (have not yet looked). I
>>> believe there is also some commercial add-ons (somewhere) that offer a SWT
>>> or JFace testing framework.
>>>
>>> Hope this helps,
>>>
>>>
>> Hey Mike,
>>
>> Thanks for the feedback. What you are saying makes perfect sense. The
>> RCP code base with which I am working suffers from design that
>> deteoriated as the code base evolved. It is not all uncommon to find
>> classes that are 1000+ lines that are a dumping ground for presentation,
>> business, and controller logic. And there are zero tests in place -
>> unit, integration or otherwise. I have been assigned the task of coming
>> up with some steps and indentifying best practices. Getting some kind of
>> testing infrastructure is at the top of my list.
>>
>>
>> I think (hope) that some getting some unit tests in place will help me
>> get the code untangled. While I don't have a lot of Eclipse RCP
>> experience, I imagine that once there is better separation concerns, my
>> presentation/UI classes will deal with a couple things - presentation
>> logic and collaboration with other components. In that scenario, I don't
>> think I would reap much benefit out of unit testing. Mocking
>> collaboraion between table, table viewer, content provider for example,
>> seems to be somewhat pointless.
>>
>> Clearly, I need both kinds of tests in place. I may need to spend some
>> time looking at TPTP or Abbott for SWT.
>
> John,
> Might I make one more (heretical) suggestion.
> It sounds like you're dealing with the 'Big Ball of Mud' pattern
> (http://www.laputan.org/mud/)! However you have one thing on your side -
> you're dealing with client-side rather than server-side code. So, unless
> the previous 'architects' used the Jobs framework or their own hand-rolled
> async tasks, you probably have an effective single-threaded app. This is a
> great advantage as you have far fewer states to consider. My approach to a
> similar task I had once was to use (and here comes the heresy) ...
> singletons. In broad terms I attempted to pull out all the
> non-presentational stuff into a model and a controller singleton. Then I
> could pull out all the stuff that was just being passed around to provide
> references and what was actually used. Once I could start to see the wood
> from the trees life became much simpler. And once I had a singleton it was
> not long before this became an instance on my plug-in
> MyPlugin.getDefault().getModel() and not long after this I started to have
> a decent-looking RCP app.
> Well - it's one idea.
> Good luck!
>
> Mike E.
Hey Mike. Just got back from vacation. You are quite the heretic! :-)
Actually, not too long ago, Spring and Hibernate were introduced into
the code base. As part of my assignment, I need to figure out how best
to integrate Spring into the RCP code.
I picked up copies of "Contributing to Eclipse" and "Eclipse Building
Commerical Quality Plug-ins". I have started reading the latter and
have already reached the conclusion that designing the app as a set of
small, (possibly) resuable plug-ins is the way to go. Currently, the
application consists of one giant monolithic plug-in. I will spend some
time searching for threads on this topic, and I may post some questions
as well.
Thanks again!
|
|
|
| Re: unit testing vs. integration testing practices [message #453133 is a reply to message #452815] |
Sun, 23 July 2006 02:34 |
John Sanda
Messages: 22
Registered: July 2009 |
Junior Member |
|
|
Mike Evans wrote:
> On Sat, 15 Jul 2006 09:26:59 -0400, John Sanda wrote:
>
>> Mike Evans wrote:
>>> On Fri, 14 Jul 2006 23:46:27 -0400, John Sanda wrote:
>>>
>>>> I am working on an RCP project and in the process of researching options
>>>> for testing code in the RCP layer of the application. I have spent a
>>>> good bit of time over the past couple days reading threads from this
>>>> newsgroup and from the swt newsgroup on testing UI code.
>>>>
>>>> As an aside, I am going to the book store to buy "Contributing to
>>>> Eclipse" tomorrow. I am very eager to read it.
>>>>
>>>> I have come across numerous discussions on unit testing that involve
>>>> starting up the workbench or initializing an entire plugin. These kinds
>>>> of tests are not unit tests. They are integration tests. The motivation
>>>> of a unit test is to test a piece of code in isolation from its
>>>> dependencies at a very granular level. I think the distinction between
>>>> unit tests and integration tests sometimes gets blurred because we use
>>>> the same APIs to write both. Both types of tests are important and are
>>>> essential testing tools.
>>>>
>>>> I apologize if I sound like I am on a rant...I'm not. I just want to
>>>> make it clear what I am trying to accomplish. In my RPC project, I want
>>>> to start developing unit tests. For example, lets say I have a
>>>> perspective with a view that display my custom composite, MyComposite.
>>>>
>>>> I want to write some unit tests for MyComposite. Are there any reasons
>>>> why I cannot or should not do something like the following?
>>>>
>>>> public class MyCompositeTest extends TestCase {
>>>> private Shell shell;
>>>>
>>>> protected void setUp() throws Exception {
>>>> shell = new Shell();
>>>> }
>>>>
>>>> protected void tearDown() throws Exception {
>>>> shell.close();
>>>> shell.dispose();
>>>> }
>>>>
>>>> public void testMyComposite() {
>>>> MyComposite composite = new MyComposite(shell);
>>>> // test behavior of MyComposite...
>>>> }
>>>> }
>>>>
>>>> MyComposite will obviously have dependencies on SWT classes and probably
>>>> JFace classes. When and where possible I would mock those dependencies
>>>> so that I could test exactly what I want in isolation. Is this a
>>>> reasonable approach?
>>>>
>>>> Thanks and I am definitely learning a lot from these newsgroups!
>>> I understand your distinction between unit and integration testing, but in
>>> this age of agile development may I be a little heretical and suggest that
>>> unit tests as you suggest might not be worth it?
>>>
>>> I tried a similiar 'white box' testing framework to what I think you are
>>> suggesting and realised early that to be in any way useful it would have to
>>> emulate most of the platform behaviour anyway. The principle reason for
>>> this was that the core of my GUI are (unsurprisingly) Views, Editors &
>>> JFace Viewers. Their lifecycles and interactions (and hence much of
>>> testable GUI bahviour) are intimiately bound to the platform and each
>>> other. Hence in the end I was spending all my time debuggin my emulation
>>> rather than any useful code.
>>>
>>> My hand-rolled solution was to build a JUnit framework INTO my app so that
>>> whne it runs up it can then self-test. Of course now there is the TPTP
>>> project that might offer something much better (have not yet looked). I
>>> believe there is also some commercial add-ons (somewhere) that offer a SWT
>>> or JFace testing framework.
>>>
>>> Hope this helps,
>>>
>>>
>> Hey Mike,
>>
>> Thanks for the feedback. What you are saying makes perfect sense. The
>> RCP code base with which I am working suffers from design that
>> deteoriated as the code base evolved. It is not all uncommon to find
>> classes that are 1000+ lines that are a dumping ground for presentation,
>> business, and controller logic. And there are zero tests in place -
>> unit, integration or otherwise. I have been assigned the task of coming
>> up with some steps and indentifying best practices. Getting some kind of
>> testing infrastructure is at the top of my list.
>>
>>
>> I think (hope) that some getting some unit tests in place will help me
>> get the code untangled. While I don't have a lot of Eclipse RCP
>> experience, I imagine that once there is better separation concerns, my
>> presentation/UI classes will deal with a couple things - presentation
>> logic and collaboration with other components. In that scenario, I don't
>> think I would reap much benefit out of unit testing. Mocking
>> collaboraion between table, table viewer, content provider for example,
>> seems to be somewhat pointless.
>>
>> Clearly, I need both kinds of tests in place. I may need to spend some
>> time looking at TPTP or Abbott for SWT.
>
> John,
> Might I make one more (heretical) suggestion.
> It sounds like you're dealing with the 'Big Ball of Mud' pattern
> (http://www.laputan.org/mud/)! However you have one thing on your side -
> you're dealing with client-side rather than server-side code. So, unless
> the previous 'architects' used the Jobs framework or their own hand-rolled
> async tasks, you probably have an effective single-threaded app. This is a
> great advantage as you have far fewer states to consider. My approach to a
> similar task I had once was to use (and here comes the heresy) ...
> singletons. In broad terms I attempted to pull out all the
> non-presentational stuff into a model and a controller singleton. Then I
> could pull out all the stuff that was just being passed around to provide
> references and what was actually used. Once I could start to see the wood
> from the trees life became much simpler. And once I had a singleton it was
> not long before this became an instance on my plug-in
> MyPlugin.getDefault().getModel() and not long after this I started to have
> a decent-looking RCP app.
> Well - it's one idea.
> Good luck!
>
> Mike E.
Hey Mike. Just got back from vacation. You are quite the heretic! :-)
Actually, not too long ago, Spring and Hibernate were introduced into
the code base. As part of my assignment, I need to figure out how best
to integrate Spring into the RCP code.
I picked up copies of "Contributing to Eclipse" and "Eclipse Building
Commerical Quality Plug-ins". I have started reading the latter and
have already reached the conclusion that designing the app as a set of
small, (possibly) resuable plug-ins is the way to go. Currently, the
application consists of one giant monolithic plug-in. I will spend some
time searching for threads on this topic, and I may post some questions
as well.
Thanks again!
|
|
|
| Re: unit testing vs. integration testing practices [message #453146 is a reply to message #452815] |
Mon, 24 July 2006 01:35 |
John Sanda
Messages: 22
Registered: July 2009 |
Junior Member |
|
|
Mike Evans wrote:
> On Sat, 15 Jul 2006 09:26:59 -0400, John Sanda wrote:
>
>> Mike Evans wrote:
>>> On Fri, 14 Jul 2006 23:46:27 -0400, John Sanda wrote:
>>>
>>>> I am working on an RCP project and in the process of researching options
>>>> for testing code in the RCP layer of the application. I have spent a
>>>> good bit of time over the past couple days reading threads from this
>>>> newsgroup and from the swt newsgroup on testing UI code.
>>>>
>>>> As an aside, I am going to the book store to buy "Contributing to
>>>> Eclipse" tomorrow. I am very eager to read it.
>>>>
>>>> I have come across numerous discussions on unit testing that involve
>>>> starting up the workbench or initializing an entire plugin. These kinds
>>>> of tests are not unit tests. They are integration tests. The motivation
>>>> of a unit test is to test a piece of code in isolation from its
>>>> dependencies at a very granular level. I think the distinction between
>>>> unit tests and integration tests sometimes gets blurred because we use
>>>> the same APIs to write both. Both types of tests are important and are
>>>> essential testing tools.
>>>>
>>>> I apologize if I sound like I am on a rant...I'm not. I just want to
>>>> make it clear what I am trying to accomplish. In my RPC project, I want
>>>> to start developing unit tests. For example, lets say I have a
>>>> perspective with a view that display my custom composite, MyComposite.
>>>>
>>>> I want to write some unit tests for MyComposite. Are there any reasons
>>>> why I cannot or should not do something like the following?
>>>>
>>>> public class MyCompositeTest extends TestCase {
>>>> private Shell shell;
>>>>
>>>> protected void setUp() throws Exception {
>>>> shell = new Shell();
>>>> }
>>>>
>>>> protected void tearDown() throws Exception {
>>>> shell.close();
>>>> shell.dispose();
>>>> }
>>>>
>>>> public void testMyComposite() {
>>>> MyComposite composite = new MyComposite(shell);
>>>> // test behavior of MyComposite...
>>>> }
>>>> }
>>>>
>>>> MyComposite will obviously have dependencies on SWT classes and probably
>>>> JFace classes. When and where possible I would mock those dependencies
>>>> so that I could test exactly what I want in isolation. Is this a
>>>> reasonable approach?
>>>>
>>>> Thanks and I am definitely learning a lot from these newsgroups!
>>> I understand your distinction between unit and integration testing, but in
>>> this age of agile development may I be a little heretical and suggest that
>>> unit tests as you suggest might not be worth it?
>>>
>>> I tried a similiar 'white box' testing framework to what I think you are
>>> suggesting and realised early that to be in any way useful it would have to
>>> emulate most of the platform behaviour anyway. The principle reason for
>>> this was that the core of my GUI are (unsurprisingly) Views, Editors &
>>> JFace Viewers. Their lifecycles and interactions (and hence much of
>>> testable GUI bahviour) are intimiately bound to the platform and each
>>> other. Hence in the end I was spending all my time debuggin my emulation
>>> rather than any useful code.
>>>
>>> My hand-rolled solution was to build a JUnit framework INTO my app so that
>>> whne it runs up it can then self-test. Of course now there is the TPTP
>>> project that might offer something much better (have not yet looked). I
>>> believe there is also some commercial add-ons (somewhere) that offer a SWT
>>> or JFace testing framework.
>>>
>>> Hope this helps,
>>>
>>>
>> Hey Mike,
>>
>> Thanks for the feedback. What you are saying makes perfect sense. The
>> RCP code base with which I am working suffers from design that
>> deteoriated as the code base evolved. It is not all uncommon to find
>> classes that are 1000+ lines that are a dumping ground for presentation,
>> business, and controller logic. And there are zero tests in place -
>> unit, integration or otherwise. I have been assigned the task of coming
>> up with some steps and indentifying best practices. Getting some kind of
>> testing infrastructure is at the top of my list.
>>
>>
>> I think (hope) that some getting some unit tests in place will help me
>> get the code untangled. While I don't have a lot of Eclipse RCP
>> experience, I imagine that once there is better separation concerns, my
>> presentation/UI classes will deal with a couple things - presentation
>> logic and collaboration with other components. In that scenario, I don't
>> think I would reap much benefit out of unit testing. Mocking
>> collaboraion between table, table viewer, content provider for example,
>> seems to be somewhat pointless.
>>
>> Clearly, I need both kinds of tests in place. I may need to spend some
>> time looking at TPTP or Abbott for SWT.
>
> John,
> Might I make one more (heretical) suggestion.
> It sounds like you're dealing with the 'Big Ball of Mud' pattern
> (http://www.laputan.org/mud/)! However you have one thing on your side -
> you're dealing with client-side rather than server-side code. So, unless
> the previous 'architects' used the Jobs framework or their own hand-rolled
> async tasks, you probably have an effective single-threaded app. This is a
> great advantage as you have far fewer states to consider. My approach to a
> similar task I had once was to use (and here comes the heresy) ...
> singletons. In broad terms I attempted to pull out all the
> non-presentational stuff into a model and a controller singleton. Then I
> could pull out all the stuff that was just being passed around to provide
> references and what was actually used. Once I could start to see the wood
> from the trees life became much simpler. And once I had a singleton it was
> not long before this became an instance on my plug-in
> MyPlugin.getDefault().getModel() and not long after this I started to have
> a decent-looking RCP app.
> Well - it's one idea.
> Good luck!
>
> Mike E.
Hey Mike. Just got back from vacation. You are quite the heretic! :-)
Actually, not too long ago, Spring and Hibernate were introduced into
the code base. As part of my assignment, I need to figure out how best
to integrate Spring into the RCP code.
I picked up copies of "Contributing to Eclipse" and "Eclipse Building
Commerical Quality Plug-ins". I have started reading the latter and
have already reached the conclusion that designing the app as a set of
small, (possibly) resuable plug-ins is the way to go. Currently, the
application consists of one giant monolithic plug-in. I will spend some
time searching for threads on this topic, and I may post some questions
as well.
Thanks again!
|
|
|
| Re: unit testing vs. integration testing practices [message #453147 is a reply to message #452815] |
Mon, 24 July 2006 01:45 |
John Sanda
Messages: 22
Registered: July 2009 |
Junior Member |
|
|
Mike Evans wrote:
> On Sat, 15 Jul 2006 09:26:59 -0400, John Sanda wrote:
>
>> Mike Evans wrote:
>>> On Fri, 14 Jul 2006 23:46:27 -0400, John Sanda wrote:
>>>
>>>> I am working on an RCP project and in the process of researching options
>>>> for testing code in the RCP layer of the application. I have spent a
>>>> good bit of time over the past couple days reading threads from this
>>>> newsgroup and from the swt newsgroup on testing UI code.
>>>>
>>>> As an aside, I am going to the book store to buy "Contributing to
>>>> Eclipse" tomorrow. I am very eager to read it.
>>>>
>>>> I have come across numerous discussions on unit testing that involve
>>>> starting up the workbench or initializing an entire plugin. These kinds
>>>> of tests are not unit tests. They are integration tests. The motivation
>>>> of a unit test is to test a piece of code in isolation from its
>>>> dependencies at a very granular level. I think the distinction between
>>>> unit tests and integration tests sometimes gets blurred because we use
>>>> the same APIs to write both. Both types of tests are important and are
>>>> essential testing tools.
>>>>
>>>> I apologize if I sound like I am on a rant...I'm not. I just want to
>>>> make it clear what I am trying to accomplish. In my RPC project, I want
>>>> to start developing unit tests. For example, lets say I have a
>>>> perspective with a view that display my custom composite, MyComposite.
>>>>
>>>> I want to write some unit tests for MyComposite. Are there any reasons
>>>> why I cannot or should not do something like the following?
>>>>
>>>> public class MyCompositeTest extends TestCase {
>>>> private Shell shell;
>>>>
>>>> protected void setUp() throws Exception {
>>>> shell = new Shell();
>>>> }
>>>>
>>>> protected void tearDown() throws Exception {
>>>> shell.close();
>>>> shell.dispose();
>>>> }
>>>>
>>>> public void testMyComposite() {
>>>> MyComposite composite = new MyComposite(shell);
>>>> // test behavior of MyComposite...
>>>> }
>>>> }
>>>>
>>>> MyComposite will obviously have dependencies on SWT classes and probably
>>>> JFace classes. When and where possible I would mock those dependencies
>>>> so that I could test exactly what I want in isolation. Is this a
>>>> reasonable approach?
>>>>
>>>> Thanks and I am definitely learning a lot from these newsgroups!
>>> I understand your distinction between unit and integration testing, but in
>>> this age of agile development may I be a little heretical and suggest that
>>> unit tests as you suggest might not be worth it?
>>>
>>> I tried a similiar 'white box' testing framework to what I think you are
>>> suggesting and realised early that to be in any way useful it would have to
>>> emulate most of the platform behaviour anyway. The principle reason for
>>> this was that the core of my GUI are (unsurprisingly) Views, Editors &
>>> JFace Viewers. Their lifecycles and interactions (and hence much of
>>> testable GUI bahviour) are intimiately bound to the platform and each
>>> other. Hence in the end I was spending all my time debuggin my emulation
>>> rather than any useful code.
>>>
>>> My hand-rolled solution was to build a JUnit framework INTO my app so that
>>> whne it runs up it can then self-test. Of course now there is the TPTP
>>> project that might offer something much better (have not yet looked). I
>>> believe there is also some commercial add-ons (somewhere) that offer a SWT
>>> or JFace testing framework.
>>>
>>> Hope this helps,
>>>
>>>
>> Hey Mike,
>>
>> Thanks for the feedback. What you are saying makes perfect sense. The
>> RCP code base with which I am working suffers from design that
>> deteoriated as the code base evolved. It is not all uncommon to find
>> classes that are 1000+ lines that are a dumping ground for presentation,
>> business, and controller logic. And there are zero tests in place -
>> unit, integration or otherwise. I have been assigned the task of coming
>> up with some steps and indentifying best practices. Getting some kind of
>> testing infrastructure is at the top of my list.
>>
>>
>> I think (hope) that some getting some unit tests in place will help me
>> get the code untangled. While I don't have a lot of Eclipse RCP
>> experience, I imagine that once there is better separation concerns, my
>> presentation/UI classes will deal with a couple things - presentation
>> logic and collaboration with other components. In that scenario, I don't
>> think I would reap much benefit out of unit testing. Mocking
>> collaboraion between table, table viewer, content provider for example,
>> seems to be somewhat pointless.
>>
>> Clearly, I need both kinds of tests in place. I may need to spend some
>> time looking at TPTP or Abbott for SWT.
>
> John,
> Might I make one more (heretical) suggestion.
> It sounds like you're dealing with the 'Big Ball of Mud' pattern
> (http://www.laputan.org/mud/)! However you have one thing on your side -
> you're dealing with client-side rather than server-side code. So, unless
> the previous 'architects' used the Jobs framework or their own hand-rolled
> async tasks, you probably have an effective single-threaded app. This is a
> great advantage as you have far fewer states to consider. My approach to a
> similar task I had once was to use (and here comes the heresy) ...
> singletons. In broad terms I attempted to pull out all the
> non-presentational stuff into a model and a controller singleton. Then I
> could pull out all the stuff that was just being passed around to provide
> references and what was actually used. Once I could start to see the wood
> from the trees life became much simpler. And once I had a singleton it was
> not long before this became an instance on my plug-in
> MyPlugin.getDefault().getModel() and not long after this I started to have
> a decent-looking RCP app.
> Well - it's one idea.
> Good luck!
>
> Mike E.
Hey Mike. Just got back from vacation. You are quite the heretic! :-)
Actually, not too long ago, Spring and Hibernate were introduced into
the code base. As part of my assignment, I need to figure out how best
to integrate Spring into the RCP code.
I picked up copies of "Contributing to Eclipse" and "Eclipse Building
Commerical Quality Plug-ins". I have started reading the latter and
have already reached the conclusion that designing the app as a set of
small, (possibly) resuable plug-ins is the way to go. Currently, the
application consists of one giant monolithic plug-in. I will spend some
time searching for threads on this topic, and I may post some questions
as well.
Thanks again!
|
|
|
Goto Forum:
Current Time: Tue Oct 15 14:44:26 GMT 2024
Powered by FUDForum. Page generated in 0.03207 seconds |
] 
Search
Help
Register
Login
Home
