• 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 private members

 
author
Posts: 799
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Other comment: one of the original promises of OO as something approaching a silver bullet came on the back of the notion of "reuse."

Many agile developers will tell you that reuse is not what they strive for, but it is a side effect of good design. If you set out to identify reusable classes in the large, from the outset, you'll have a tough time of it. Unless you're building frameworks for others to consume, the best direction to take is to build a system that works, not worrying about its reuse potential. You can do that by using TDD.

The true realization of the promise of reuse is at the code level. View every method as an opportunity from which to extract abstractions. JB's reworking of the validation code is a great example. Another classic example is the method that parses a string: it both tokenizes it and populates domain-specific fields. Abstract out the notion of tokenizing the string, and you've produced a reusable utility method. Extracting methods in this manner makes it much easier to spot the duplication.

Learn to eliminate duplication everywhere you find it. I've made a hobby of reducing the overall amount of code in a module by anywhere from 25% to 75%. This also tends to make any given method or class far easier to comprehend, maintain, and debug.

-j-
 
Ranch Hand
Posts: 995
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Superb answer J.B. and a great solution.

./pope
 
Ranch Hand
Posts: 241
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Jeff Langr:
Excellent answer JB!



I agree too ... Excellent solution ...
It shows how to solve the problem and the benefits of use it.
I really appreciate you answer ..

Regards,
 
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
Vinicius,
Other posters have explained and quoted the spec quite well. I just want to explain what we are doing. For the most part, I avoid reflection. But I have a few tests that were easier to implement that way.

I have some unit tests that test a wrapper to the EJB. The tests are run in Eclipse's JRE. The EJB itself is run in the EJB container. Note that these are pure unit tests. They mock out the EJB itself (but are in the ejb jar.)

Now that I think about it, your question relates more to integration tests that test the real EJB. For integration tests, I limit myself to the public interface. Anything more detailed is tested in the unit tests. There isn't any logic in the EJBS - they just delegate to commands. So there isn't anything to unit test and the integration tests cover well.
 
Eusebio Floriano
Ranch Hand
Posts: 241
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Jeanne Boyarsky:
Vinicius,
Other posters have explained and quoted the spec quite well. I just want to explain what we are doing. For the most part, I avoid reflection. But I have a few tests that were easier to implement that way.

I have some unit tests that test a wrapper to the EJB. The tests are run in Eclipse's JRE. The EJB itself is run in the EJB container. Note that these are pure unit tests. They mock out the EJB itself (but are in the ejb jar.)

Now that I think about it, your question relates more to integration tests that test the real EJB. For integration tests, I limit myself to the public interface. Anything more detailed is tested in the unit tests. There isn't any logic in the EJBS - they just delegate to commands. So there isn't anything to unit test and the integration tests cover well.



I got what you were trying to explain .. )
The ejb classes just delegate the request to the classes which are responsable for the business rules. And you should test this classes, right?
Now i realized what you were talking about .. )

Regards,
 
Jeanne Boyarsky
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

Originally posted by Vinicius Boson:
The ejb classes just delegate the request to the classes which are responsable for the business rules. And you should test this classes, right? )


Exactly!
 
author
Posts: 45
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If I want to test private methods or data, I take it as a signal that I have a design problem, not a testing problem. If I solve the testing problem, I miss the opportunity to improve the design. Some times I can't think of a way of improving the design. Then I test what I can.

Kent Beck
Three Rivers Institute
 
Alexandru Popescu
Ranch Hand
Posts: 995
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Sometimes big problems have simple solutions .

Kent should I understand that you are not going for testing private methods?

./pope
 
Alexandru Popescu
Ranch Hand
Posts: 995
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have found another testing framework: bwnunit which promises a Private Proxy to allow private method testing:


The Private Proxy is designed to make protected, package and private variables and methods accessible to developers to enhance their ability to create unit tests.. Developers can use this class to simply call a private method on an object for testing purposes. Developers will also be able to tinker with the internally object references to update them to different values to see how the Object being tested handles wacky values for parameters.



./pope
 
reply
    Bookmark Topic Watch Topic
  • New Topic