Unit testing is so hard to understand for me!

[Paul Duer]

Hi guys,
I am still trying to get my head around unit testing. And I have questions.
I develop apps in Struts alot, so I use StrutsTestCase and Junit to write tests to test the actions often. I also do some unit testing on my beans and classes but not as much.
My problem is this. I want to test actions. I want to be able to have tests for a given app that can be run to "sanity check" changes.
Often team members will change a class somewhere way down in the heirarchy, and that's what I want to catch.
But, I feel like to truly test an Action, you have to have data and run your action.
That's were it all breaks down for me. Because that Data has to be pristene. For example I have an action that loads a page full of inputs. Well I have to have a record in the database the matches exactly with what I would expect to come out on the page.
Am I missing something? Is there an easier way?

[Jeanne Boyarsky]

You are trying to test a lot in one test. Try to break it up. It's usually easier to separate the back end and front end tests. The back end test can check that it is getting the correct data from the database (possibly by writing in a dummy record so you know what is there.) The front end test can check that given certain data, it does what it is supposed to.
I try to write tests that are as small as possible (even class level) so that when a test breaks, it is easy to find out why. You may want to look into MockObjects. They provide dummy implemenations of session, request, response, ... - that way you can test without the server.

[Lasse Koskela]

MockObjects also gives you a framework for mocking up a Connection/Statement/ResultSet, which allows you to drop the database completely from the equation.

[Paul Duer]

Thank you both for your suggestions, I really think Mocks are the way to go. And then also to have tests below the mocks that test the classes into the database.
I guess the hard part is you have to break away from being a bad programmer if you plan to unit test.
You know, you get used to writing these big controllers or actions with lots of business logic creeping in. So you try to write test that take all the inputs and get the result.
It seems when you unit test, you have to make sure things are defined in units. For example if you have some process that performs task A and then you need to add task B, you don't just go around to anything using A and make it work for B as well. With unit testing you have to go to the heart of task A does and rewrite things so that task B is fully supported along with A.
It's almost like welding a hole instead of patching it with glue? Make any sense?

[Ernest Friedman-Hill]

I'm actually not sure about what you mean in your last two paragraphs, but I do want to agree that unit testing forces you to design software differently, and that's a good thing. It forces you to design things in a modular way to make testing easier, and this generally improves the maintainability of the software.

[Jeanne Boyarsky]

"I guess the hard part is you have to break away from being a bad programmer if you plan to unit test."
Paul, I think that sums it up really well. XP says something similar where you have to write "testable code."

[Burk Hufnagel]

Paul,
Are you the only one writing unit tests? If so then you've got a major job ahead. If not, then the tests for the classes you're dependent on should tell you when things go wrong.
If you are the only one, then I'd suggest writing a few simple tests for those classes so you'll know when someone's changed things in a fatal way.
Good Luck!