unit testing methods which returns objects?

[Elhanan]

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?

 

[Lew]

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