Unit testing bad

More on unit testing and TDD – it’s good and it’s got momentum. As Steven Feuerstein commented on a previous post of mine, “deficient testing is generally an ongoing worldwide crisis in the software industry”. And no more so than in the database, I’d warrant.

However, whatever tier we’re testing, with whatever technology, I’m uncomfortable with unit testing dictating which methods/procedures/etc are public and which are private within a class/package/etc. Taking it to the extreme, you’re almost saying that unit testing is more important than security and code access control.

I believe that one possible approach in Java is to circumvent the access control using Reflection. Not something I know much about.

But there is no such mechanism in the database.

One approach might be to use conditional compilation. However, in general, my feelings are that conditional compilation solves a nonexistent problem. I don’t like the idea of testing a piece of code that might have conditional compilation clause changing what and how it does something between Dev, Test and Prod environments or between different versions.

In general, if you can refactor a routine into a packaged function or procedure then that makes sense and it makes sense to expose it as a testable unit.

But all this does not make private procedures and functions redundant. No way.

Advertisements

3 Responses to Unit testing bad

  1. chet says:

    I’ve struggled with unit testing of private procedures/functions myself. Awhile back I was doing pretty extensive database testing with SQLUnit, but the only way to test those private functions or procedures was to make them public…thus forcing you to change your code before checkin and obviating the purpose of the unit test.

    I have used JUnit (for Java), I wonder how it deals with private classes…

    chet

  2. chet says:

    I meant “haven’t used JUnit…” up above

  3. chris says:

    Hi!

    Unit testing is a topic I’m very interested in, too.

    A possible solution for the access control problem you mentioned is adding yet another layer. Say, you have a package my_business_logic. It could be a thin wrapper around my_business_logic_impl which actually does the job and exposes all it’s internals for the test packages.

    Of course, it’s overhead (and the wrapper my_business_logic needs unit tests … again ;-)).

    Chris

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: