wood burning stoves 2.0*
The moose likes Testing and the fly likes Unit testing is so hard to understand for me! Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » Testing
Bookmark "Unit testing is so hard to understand for me!" Watch "Unit testing is so hard to understand for me!" New topic
Author

Unit testing is so hard to understand for me!

Paul Duer
Ranch Hand

Joined: Oct 10, 2002
Posts: 98
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
internet detective
Marshal

Joined: May 26, 2003
Posts: 29249
    
139

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.


[Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Blogging on Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, OCAJP, OCPJP beta, TOGAF part 1 and part 2
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
MockObjects also gives you a framework for mocking up a Connection/Statement/ResultSet, which allows you to drop the database completely from the equation.


Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Paul Duer
Ranch Hand

Joined: Oct 10, 2002
Posts: 98
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
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24166
    
  30

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.


[Jess in Action][AskingGoodQuestions]
Jeanne Boyarsky
internet detective
Marshal

Joined: May 26, 2003
Posts: 29249
    
139

"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
Ranch Hand

Joined: Oct 01, 2001
Posts: 814
    
    3
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!


SCJP, SCJD, SCEA 5 "Any sufficiently analyzed magic is indistinguishable from science!" Agatha Heterodyne (Girl Genius)
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Unit testing is so hard to understand for me!
 
Similar Threads
Some Rookie Testing Questions
testing vocabulary - do you agree with this vocabulary?
Estimating Test Development and Test Coverage
Non J2EE transactional management in Java
Including maven test classes in to my war?