Home > Archive > Extreme Programming > August 2005 > JUnit
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| Ananth 2005-08-04, 5:02 pm |
| Hi,
Probably some questions are not good to ask in THIS forum. anyway let
me ask...
1. I would like to know when JUnit is NOT Recommended for Unit testing
(in such cases which is the alternative mechanism)
2. I have a team which has not used JUnit for unit testing before. What
can I do to reduce the risks?
3. For an application of size 800 FPs what would be the effort involved
for writing JUnit Test Cases. There are around 98 use-cases
Thanks
Ananth
| |
|
| Ananth wrote:
> Probably some questions are not good to ask in THIS forum. anyway let
> me ask...
>
> 1. I would like to know when JUnit is NOT Recommended for Unit testing
> (in such cases which is the alternative mechanism)
When you are not using Java. Otherwise, use JUnit.
> 2. I have a team which has not used JUnit for unit testing before. What
> can I do to reduce the risks?
Your own research must come first. There are significant risks when getting
this stuff wrong. Common anti-patterns are using tests to increase velocity
and add features nobody needs, to use tests to support poorly factored code,
and adding features between testing because that seems easy. You must start
using TDD as your own primary implementation technique before leading
Next, use "Nail Soup". Say we got this great new editor called Eclipse, and
it will make code easier to write. Oh, and you can turn code pink if its
test fails. Etc.
> 3. For an application of size 800 FPs what would be the effort involved
> for writing JUnit Test Cases. There are around 98 use-cases
The effort will be much, much lower than writing test-free code and
debugging it. Start there, and questions about long term effort become less
relevant.
--
Phlip
[url]http://www.greencheese.org/Z Land[/url] <-- NOT a blog!!!
| |
| Shane Mingins 2005-08-04, 5:02 pm |
| "Ananth" <Anan_sns@yahoo.co.in> wrote in message
news:1123176123.245403.63290@g44g2000cwa.googlegroups.com...
> Hi,
>
> Probably some questions are not good to ask in THIS forum. anyway let
> me ask...
Adding to other replies ...
A great group is the JUnit group at yahoo.
A great book about using JUnit is JUnit Recipes by J.B. Rainsberger.
There is some getting started material at the JUnit site
http://www.junit.org/index.htm
HTH
Shane
--
Put improvement to work by not waiting for perfection.
Find a starting place, get started, and improve from there.
XPE2E - Kent Beck
| |
| John Roth 2005-08-04, 5:02 pm |
|
"Ananth" <Anan_sns@yahoo.co.in> wrote in message
news:1123176123.245403.63290@g44g2000cwa.googlegroups.com...
> Hi,
>
> Probably some questions are not good to ask in THIS forum. anyway let
> me ask...
>
> 1. I would like to know when JUnit is NOT Recommended for Unit testing
> (in such cases which is the alternative mechanism)
>
> 2. I have a team which has not used JUnit for unit testing before. What
> can I do to reduce the risks?
>
> 3. For an application of size 800 FPs what would be the effort involved
> for writing JUnit Test Cases. There are around 98 use-cases
>
> Thanks
> Ananth
Just ran across this two year old series of articles that might shed
a bit of light on your decision making process.
They don't deal with JUnit specifically, but they do give some background
on when to use various kinds of tools and what for.
http://www.testing.com/cgi-bin/blog...sting-project-1
John Roth
>
| |
| Ananth 2005-08-05, 5:01 pm |
| Thanks that was very helpful.
I have reports and charts generated by other tools in my application.
Will I able to test these reports/ charts etc. with JUnit?
Thanks
Ananth
| |
|
| Ananth wrote:
> I have reports and charts generated by other tools in my application.
> Will I able to test these reports/ charts etc. with JUnit?
_Should_ you test them? It depends on whether you will refactor them. Some
reports are just one-shots.
_Could_ you test them? It depends on the tool. If you emit HTML or PS, and a
tool reads that, you should test-first your own pipeline, and should parse
that HTML or PS to spot-check it. Then you test-first by writing a test that
fails a spot-check, then you improve your pipeline to provide the effect.
HTML, as XHTML, submits easily to XPath. I don't know about a parser for
PostScript. You could write one - just cheap enough to support testing - or
in this situation you could switch to XML and "formatting objects" or
whatever, then pipe that into PostScript.
So it depends on your tool whether and how you should test it. If your tool
has a Java binding, AND if this binding can query a report's state, then you
could use that and not worry about the script.
--
Phlip
[url]http://www.greencheese.org/Z Land[/url] <-- NOT a blog!!!
|
|
|
|
|