• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Unit testing is so hard to understand for me!

 
Ranch Hand
Posts: 98
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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?
 
author & internet detective
Posts: 41860
908
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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?
 
author and iconoclast
Posts: 24207
46
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
Posts: 41860
908
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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."
 
Ranch Hand
Posts: 883
3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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!
 
I think he's gonna try to grab my monkey. Do we have a monkey outfit for this tiny ad?
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic