File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Unit testing is so hard to understand for me!

 
Paul Duer
Ranch Hand
Posts: 98
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
author & internet detective
Marshal
Posts: 33671
316
Eclipse IDE Java VI Editor
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
author
Sheriff
Posts: 11962
5
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 98
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 24204
34
Chrome Eclipse IDE Mac OS X
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
author & internet detective
Marshal
Posts: 33671
316
Eclipse IDE Java VI Editor
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
"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
Posts: 814
3
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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!
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic