unit testing methods which returns objects?

Discussion in 'Java' started by Elhanan, Feb 4, 2007.

  1. Elhanan

    Elhanan Guest

    hi..

    i'm developing a framework which read an xml file an returns objects
    from it (don't say data-binding the xml is far more complext for
    that), my idea is to develop a class which reads a portion of the xml
    returns an object and will call recursivlye on another instance of
    itself , and so on..

    first of all i will be using test data from a file as placing the xml
    in a string sounds silly to me, problem is, how exactly should i test
    the object returnd? should i implement equels and set up a fixture of
    said objects?
    Elhanan, Feb 4, 2007
    #1
    1. Advertising

  2. Elhanan

    Lew Guest

    Elhanan wrote:
    > hi..
    >
    > i'm developing a framework which read an xml file an returns objects
    > from it (don't say data-binding the xml is far more complext for
    > that),


    Data binding.

    The very definition of "data binding" is, for XML files, to "read an xml file
    an[d] return... objects from it".

    Is this XML validatable, i.e., schema-constrained? If so, JAXB probably can do
    the job better than a hand-rolled parser.

    That said, I have had excellent fortune making SAX-based parsers that
    customize the XML-to-object mapping without using prebuilt data-binding
    libraries, or even DOM-based ones.

    > my idea is to develop a class which reads a portion of the xml
    > returns an object and will call recursivlye on another instance of
    > itself , and so on..


    Your "call recursively another instance of itself" is more likely better
    realized as a set of subclasses of a common interface for a parser element,
    the choice of implementing class determined by runtime context. Your parser
    would run in a loop, grabbing XML tokens and passing each to an appropriate
    subclass instance of your interface.

    > first of all i will be using test data from a file as placing the xml
    > in a string sounds silly to me, problem is, how exactly should i test
    > the object returnd? should i implement equels and set up a fixture of
    > said objects?


    I have no idea what you mean by a "fixture". Value object types nearly always
    have to override equals() and hashCode().

    There are many possible interpretations of what it is to "test the object
    return[e]d".

    Unit tests can be regularized using a framework like JUnit, and should be.
    These basically exercise the API of your application, ensuring that your
    algorithmic invariants hold. For example, one unit test might ensure that
    "setProperty( null )" throws a NullPointerException (or that it doesn't).

    If by "to test" you mean "to apply business logic to" the object, i.e., to
    implement some action in your problem domain, then we are unable to answer
    your question absent knowledge of your intended business logic. If you were to
    tell us your intended business logic, you will have answered your own question.

    - Lew
    Lew, Feb 4, 2007
    #2
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. John Maclean
    Replies:
    1
    Views:
    328
    Martin P. Hellwig
    Apr 13, 2010
  2. Ulrich Eckhardt

    unit-profiling, similar to unit-testing

    Ulrich Eckhardt, Nov 16, 2011, in forum: Python
    Replies:
    6
    Views:
    313
    Roy Smith
    Nov 18, 2011
  3. Michal
    Replies:
    4
    Views:
    118
    Robert Klemme
    Dec 29, 2004
  4. Bill Mosteller
    Replies:
    0
    Views:
    202
    Bill Mosteller
    Oct 22, 2009
  5. Avi
    Replies:
    0
    Views:
    472
Loading...

Share This Page