Testing Java
in [Java Programming]
|
Prev: Java Swing Question: Robot Screenshot does odd things when close to the mouse cursor
Next: Does launching an applet via JNLP work on Linux at all?
From: Arne Vajhøj on 23 Feb 2010 18:28 On 23-02-2010 16:45, Rhino wrote: > I'm worried that my knowledge of industry standard testing procedures for > Java is getting a bit out of date. > > Can anyone refer me to a website that focuses on testing for Java code and > that describes the best practices and tools for doing that testing? > > I am a one-man development team at the moment and I want to be sure that my > code is going to be considered thoroughly tested when I eventually release > it. > > Some guidance on what should be tested and how thoroughly it should be > tested - as well as what does NOT need to be tested - would be very helpful. What type of testing. If unit testing look for JUnit. For other types of testing you may need other tools. Arne
From: Arne Vajhøj on 23 Feb 2010 18:30 On 23-02-2010 18:00, Joshua Cranmer wrote: > On 02/23/2010 05:45 PM, Martin Gregorie wrote: >> IME its well worth the effort of writing a scriptable regression test >> harness for any chunk of code that's more complex than, say, a package >> that writes and parses CSV files. > > After having found a bug in a simple getter, I've found it easier to > recommend to always write a test for everything, no matter how simple it > is. Very good point. Before IDE's generated getters/setters it occasionally happened that those were copy pasted, method name modified but field name was not modified. > Also, any time you find and fix a bug, add a check for it in your test > suite to make sure you don't regress the bug fix. Also very good point. If one person at some point in the past did not think of a potential problem, then there is a much higher risk than usual for that during some heavy refactoring another person will not think of it either. Arne
From: Martin Gregorie on 23 Feb 2010 19:03 On Tue, 23 Feb 2010 18:00:19 -0500, Joshua Cranmer wrote: > On 02/23/2010 05:45 PM, Martin Gregorie wrote: >> IME its well worth the effort of writing a scriptable regression test >> harness for any chunk of code that's more complex than, say, a package >> that writes and parses CSV files. > > After having found a bug in a simple getter, I've found it easier to > recommend to always write a test for everything, no matter how simple it > is. > That goes without saying - I wasn't being entirely clear. What I meant is that its not worth writing a test harness for a very simple class, e.g. one with nothing but getters, setters and toString() methods. However, if a class or group of co-operating classes is complex enough to deserve a test harness, then you must test all its methods. If a method in such a class 'doesn't need testing' then you should be asking whether the method is really necessary and remove it if it isn't. > Also, any time you find and fix a bug, add a check for it in your test > suite to make sure you don't regress the bug fix. > Yes. The set of test scripts should be extended if it misses bugs and *must* be extended if extra functionality or methods are added to the class. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
From: Jean-Baptiste Nizet on 24 Feb 2010 07:07 Rhino a �crit : > I'm worried that my knowledge of industry standard testing procedures for > Java is getting a bit out of date. > > Can anyone refer me to a website that focuses on testing for Java code and > that describes the best practices and tools for doing that testing? My advice would also be to test everything. Now for the tools: JUnit and TestNG are certainly the most used test frameworks. I use Cobertura, which is free, to measure the code coverage of the tests. You might also like Emma or Clover (but this last one isn't free). To test web applications, I use HtmlUnit, but there are other tools (Selenium is probably one of the most used tools). Finally, these are not really testing tools, but they help avoiding bugs, bad practices and ugly code: PMD, Checkstyle, and Findbugs are great tools. All of them can easily be included in your build. See http://code.google.com/p/memwords/source/browse/trunk/ant/build.xml for an example of an ant build which integrates all these tools. I should also mention that if your application and/or your team becomes larger, running the tests frequently can become tedious. You might then add a continuous integration tool like Hudson to your toolbox. JB.
From: Tom Anderson on 24 Feb 2010 19:23
On Tue, 23 Feb 2010, Arne Vajh?j wrote: > On 23-02-2010 18:00, Joshua Cranmer wrote: > >> Also, any time you find and fix a bug, add a check for it in your test >> suite to make sure you don't regress the bug fix. > > Also very good point. > > If one person at some point in the past did not think of a > potential problem, then there is a much higher risk than > usual for that during some heavy refactoring another person > will not think of it either. Something i say that's just about applicable here is "If something can break, test it. If something can't possibly break, definitely test it.". When you make assumptions like that, you need to check them, and you'll get bitten if you don't. tom -- Hesgadin. It was in two parts - both of them silent. I remember this map came with a letter accusing me of stealing eggs. I had never understood the relationship of the map to the accusation. I still don't, but I'm grateful for the map. |