Mike,
Do you mean the part about writing the code first, and
then testing or writing the test first and then
coding?
Let me just suppose that that is it.
Here's what I do.
When ever I'm working with a new API,
I start with a JUnit test.
Then I define what I want to do in a little cookbook
item like this:
Challenge
Load Maven Pom File
Solution
See Discussion (Because it's not really a quicky)
Discussion
First Create the ResourceSet
ResourceSet resourceSet = new ResourceSetImpl();
Then create a URI pointing to the object
URI uri = ....
Then I take the process / solution
that I'm trying to validate that works
and put it in the JUnit test.
Then I run the test.
And keep tweaking until I get it right.
As I tweak I make updates to the cookbook,
just so I can remember what I did :-)
A test is code and code is code.
I like the test first concept because
it encourages you to break the step you are doing
into a few lines that are easy to test and asks
you to validate your thinking. By doing this you have
confidence in your code.
That said it's nice when your tests verify your code
continuosly.
So with what I did above it's possible that I tested
my "Challenge" using JUnit,
then copied and pasted the code into a method, and
this method also contained other code.
Now I broke my ability to continously test that
"section" of code as the .java file is updated...It's
possible that someone applies a patch that overwrites
it...the test still passes, but the actual code is
broken...
But that's an easy thing to fix...just mentioned it
because it's important...
Cheers,
- Ole
--- Mike Bria <
bria526xp@...> wrote:
> OIe --
>
> Just curious if you had any comment on my question
> to you earlier in the
> chain. Thanks!
>
> --MB
>
>
> [Non-text portions of this message have been
> removed]
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com