Now, with the frustration above, I thought "maybe they already have this and I am just not using it". Well, that's the case here. In WSAD / Eclipse, go to your JUnit dialog, look at the "Hierarchy" tab / view / whatever, and then right click on it and do "Rerun". Ta-da! So you can run a "TestSuite", a "TestCase" and a method within a test case class. Three levels of granularity.
I wish that I have been using that long ago... damn. The tools are there, but learning them takes time etc. Mostly it takes itch to scratch for the change in behaviour to happen.
Listening to: Roxy Music - More Than This
While this is handy, your problem may be a symptom os a bigger problem.
ReplyDeleteWhy do you want to run only one test instead of a whole test case? Do you have dependencies between test methods? Does running the whole test case take too long?
Ideally you'll want to run the whole test case to make sure you didn't introduce a regression anywhere else in the class you're testing. Even more ideally, you want to run the whole *suite* to make sure you didn't introduce a regression anywhere in the project.
If the test runs take too long, then you'll be less likely to run them, introduce regressions without knowing it and not find them as quickly.
... that's probably not the case here, but I'm just curious. :)
It's more to do with if you use a debugger or (*gasp*) put println's in your code... you may not want to step through 20 test cases to get to the one that you're trying to take a look at.
ReplyDeleteOne thing here, yes, our tests *are* too slow for my liking. We have a good idea how to fix them, but have not made the change yet. Running the whole suite takes about 1 min (in container) so it's not that bad, but it will get worse. It's just an issue of being able to put someone on the task right now.
This has an impact on how often developers use the test suite and find regressions. If it becomes to unwieldy, you give developers an excuse not to use it.
ReplyDeleteI remember way back when I first read about XP and test-first. I think it was Beck that talked about the importance of having a quick test suite, otherwise it defeats its own purpose. He advocated small fixes/changes and running the suite often.
One thing that I was considering was to have as a "test db" a hsqldb db. I was reading that it has a "in memory" mode so I figured that would make the tests really fast.
ReplyDeleteHowever, for the problems that it would probably introduce (small differences between it and Oracle) it would kill me I think.
What would really help out (a lot of people I would think) would be able to use your db "in memory". If you're running lots of tests, then likely you're db is small and wouldn't have a big footprint. It would be faster. ;-)
Does anyone know how to use Oracle in memory? :-)
Sometimes it's nice to be able to just run 1 test. Like if a test fails, and you look at the code, and realize that you probably should have put > instead of >=. So you switch it up. You only want to rerun the single test that failed. If the test passes, you should probably run the whole test suite again, to make sure that your change didn't affect anything else, but if it fails, you can look into changing something else. You don't really need to rerun the whole test suite until the test that is failing passes.
ReplyDeleteI don't really agree with that. If your tests are fast enough, it actually takes *less* effort to run the whole TestCase file rather that just running one test.
ReplyDeleteOtherwise you'll be working away always just running the "latest" test you are working on and you won't notice when one little, tiny change that you just did that *shouldn't* have affected anything else blows up all or some your other tests. Trust me, it's happened to me.
I agree about not *always* running the whole suite though... that usually takes a while regardless. Running as many tests as possible is always a good thing though. I just use the "run one test thing" for when I am stepping through the code... it's nice that way.