Re: Unit testing - Breaking bad habits

james.bartow@xxxxxxxxx wrote:
I'm interested in practicing at least some level of Test Driven
Design. The problem is that I'm so set in my ways that it's hard to
see the "right" way to do this. Particularly as I do a lot of CRUD-
style Web work, my code doesn't resemble the simple examples very
much, and Mock objects isn't where I'd prefer to start.

If it was TDD then you would have started with the tests.

:-)

Here's an example app: It comes in three parts: (This is the
simplified version)
One is a Bean that pulls XML messages off a JMS queue, parses them,
and inserts the resulting data into a DB.
The second piece is a client jar that presents a DTO. When the DTO is
populated, it can be passed to a send() routine that converts the DTO
data into XML and drops it on the JMS queue.
The third piece is a simple web-based search form that searches the DB
for matching terms and displays them.

Where should/should I not use tests?
Testing that each of the above pieces "work" seems too high level for
unit testing, but many of the components are dependent on dynamic data
and/or DB.
I can test that a given DTO will generate the correct XML, but do I
want to test that in one large pass, or do I run a different test for
each DTO data element?
Likewise how do I test my XML parsing - I don't want to test that
XPath works, but testing that the data shows up in the DB seems too
late for unit testing.
And testing the web form just confuses me. I don't want to query the
DB, I don't want to test the webserver itself, but there's very little
logic to test outside of the framework. I know I can try higher-level
testing packages to test the full process, and I eventually want to,
but I'm trying to learn TDD here.

You should unit test all 3 pieces.

* setup that create test database, create test queue and put known XML message in it
* call code
* check that database contains what it should

* setup that create test queue and populate DTO with known values
* call send
* check that message in queue contains what it should

* setup that create test database with know data
* send HTTP POST
* check response data

If you can find a good mockup implementation for database and
queue, then it would be more pure unit tests, but if not then
just go for the real thing. I am not a purist.

Arne
.

Relevant Pages

  • Re: Representing Biz Entity in XML: Use XMLSerializer or custom using XSD?
    ... XML, it seems like your saying that it should be able to represent itself as ... the DTO might be thought of as the "Export" version of the BE. ... does it still make sense to maintain a separate XSD ... read-only properties that says "serialize, ...
    (microsoft.public.dotnet.framework.webservices)
  • Re: Unit testing - Breaking bad habits
    ... One is a Bean that pulls XML messages off a JMS queue, parses them, ... The second piece is a client jar that presents a DTO. ... unit testing, but many of the components are dependent on dynamic data ... I wouldn't see much need to test the XML parsing ...
    (comp.lang.java.programmer)
  • Re: Unable to cast MSMQ body to an object
    ... why wouldn't it use the one on the queue? ... converting it to XML anyway. ... I think this should work for an XML formatter ... You can find a decent xml serialization demo here: ...
    (microsoft.public.dotnet.languages.csharp)
  • Unit testing - Breaking bad habits
    ... One is a Bean that pulls XML messages off a JMS queue, parses them, ... The second piece is a client jar that presents a DTO. ... unit testing, but many of the components are dependent on dynamic data ... In this case it's a completed project, ...
    (comp.lang.java.programmer)
  • Re: BizTalk Large Image
    ... If you drop the message in the queue, you'll need to do more processing work. ... You could probably do your message transformation by setting the xml content to a seperate message, map and then append the binary to that message. ... > end product will be a SOAP with attachments message sent to a trading> partner. ...
    (microsoft.public.biztalk.general)