• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

testing versus encapsulation

 
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I am working on a web application that has very little public methods. Internally, the application uses XML which doesn't change a lot, but in the end HTML comes out (XSL inbetween) and that is changed almost weekly.
Which leaves me with these options:
- update all my tests every week (a LOT of work),
- make the methods that return XML public (seems bad, intuitively).
- add testcode to my business classes (which I will later probably forget to remove)
Which option is best (or are there other options)?
 
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

I am working on a web application that has very little public methods.

Are you saying your web application is one big servlet?

- update all my tests every week (a LOT of work),

Would it be sufficient to test only certain invisible "markers" that tell your test code that you're looking at the correct page? These shouldn't change that often.

- make the methods that return XML public (seems bad, intuitively).

There was an interesting discussion in the JUnit Yahoo Group (I think it was this thread) about the visibility of methods. Some folks think that having only public methods is not that bad. One of the arguments was that a private method is a "smell" indicating that it should be moved into a new class (in which it would be public and could be tested easily). Also, you can use the PrivilegedAccessor class for invoking private methods. It's also available in the JUnit group.

- add testcode to my business classes (which I will later probably forget to remove)

Don't go there (for obvious reasons).
[ November 04, 2003: Message edited by: Lasse Koskela ]
 
Greenhorn
Posts: 23
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I was in the same situation as you are now i.e. updating all the testcases
to reflect the expected values. Are your expected values/results hard-coded
in your testcase? If it is, it better to remove them. Create a kind of a
ResultManager class that would generate the same expected result (for the specified parameters) that would be the output of your testcase. With this, you don't have to update all of the testcases; you might just need to update one class - ResultManager class to reflect whatever changes that might had been changed in the implementation of the function you are testing...
mavedrive;
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'd say that testing is more important than encapsulation.
And if small changes to the code tend to brake many tests, that's a strong indicator that you have coupling problem - you probably need to break up your design into smaller units to be able to test smaller chunks of functionality independently from the rest of the system.
 
author & internet detective
Posts: 41860
908
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Annekee,
Just want to mention that it's not neccessarily a choice between public and private methods. If you make your methods package-private (with no access modifier), you get a nice middle ground.
Public part:
The tests can access the methods because they are in the same package. At least they are if you follow the convention discussed in other threads.
Private part:
Only classes in the same package can access these methods. Usually developers working in the same package are on the same team. That way, you can have an understanding that you will all honor encapsulation as if the methods were private. Other teams using/reusing the code will see the methods as if they were private.
 
Annekee Dufour
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you all for replying, it really helps!
My application is not one big servlet, you are right. I do have some public methods in other classes, luckily, and I can test them. But a lot of things happen in private, and when I write new private methods, I write testcode which I remove later on (which I still think is a waste). I liked the suggestion that a lot of private methods means bad design, I will pay attention to it (so far, it didn't lead to many changes, but it's interesting anyway).
It is not so that small changes in the code were braking up many of my tests, it were big changes in XSL (I was comparing the html from the application with an 'expected html file', and the html was modified all the time by XSL changes, not by application changes). And I do not want to test that. The markers were a great idea, I use that a lot. Also, I built teststubs and simulators, so I can be more sure of the testoutput (The application does a lot of soapcalls to parties that are not always available).
I did not want to use the package private access, because I want my tests to be in a separate package for easy releasing.
Again, many thanks, this is an interesting place to be!
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Consider that a class which returns XML in a private method and returns HTML in a public method is doing two very different things. A class with a Single Responsibility to return XML would naturally have a public, testable showMeTheXML() method.
Is the test telling you to make two classes? And to eliminate references to each other?

Looks like two very testable methods.
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic