Originally posted by Junilu Lacar:
1. Changing the type of result was not so painful here because there was very little ripple effect. But what about in real-world applications? Changing types could be a lot more painful if there were existing clients. These clients would break and that could cause a ripple effect throughout the system. How do we avoid this kind of effect or at least minimize it?
2. Do we have to keep old tests around, even if only as commented out code? I would think this would provide some sort of trail for maintenance programmers later on to pick up on the "theory" of the change.
3. Wouldn't it be also advisable to write tests for failure conditions such as border conditions, lower and upper bounds checking, and such? And what about checking for exceptions we expect to be thrown in certain cases?
4. I kind of get the concept of test-first programming but how exactly do I come up with meaningful tests? Are there any guidelines? It seems to me that thinking up what tests to write is just as hard or even harder than just going out and writing the actual code to solve the problem
5. And even if we are able to think up meaningful tests, wouldn't it have been easier to think up a design first and then think of what tests we wanted? Are we really going faster by going straight to writing tests?
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by jason adam:
I too share your sentiment on if this is really as productive as it sometimes is made out to be. Perhaps we're just looking at things in the short-term too much, but if we are to write tests for every single behavior that we expect our design to exhibit, that would just get insane for a really large application. I only see this approach functional if you're working on a small system, or are organized enough to break things into logical subsystems and work those out, and then bring it all together into the larger app.
Personally, I'd rather just write a simple main method with an if/else statement testing a method of a class than bother with some of this.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Ilja Preuss:
How well does this approach work for really large applications? How is writing a simple main method preferable to some simple JUnit test cases?
How confident are you in your ability to safely refactor your code?
How much time do you spend debugging your code? How many tests would you have been able to write in the same amount of time?
Curiously, Ilja
Originally posted by Axel Janssen:
I have some problems with this all or nothing approach.
I will have to write test classes for every method.
This sounds like a lot of typing, doesn't it?
Have read a article about a project where they used test classes just for the "difficult" part of the system. What about such "dirty XP"?
In the article they stated, too, that junit isn't very good suited for GUI-apps. Is that true?
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by jason adam:
Well, writing the main method is easier just because I haven't gotten used to JUnit yet. That's one of the biggest problems I'm having right now. I completely see the value of test first, it just seems a lot of upfront work. If I ever actually get used to using JUnit, it will most likely seem like second nature after awhile.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Junilu Lacar:
Thanks Ilja
What had to be true about our design for the ripple effect to occur?
The extent and magnitute of ripple effect is an indication of how brittle your code is. The pieces may be too tightly coupled. This is a candidate for refactoring anyway so in a (sad, twisted) way, getting a ripple effect may be a good thing.
On the other hand, breaking lots of code while working under tremendous stress is not good either, morale-wise or maybe even career-wise.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Terry McKee:
One other question: What is the difference between using JUnit and the new assertions capability in JDK1.4?
Originally posted by Terry McKee:
One other question: What is the difference between using JUnit and the new assertions capability in JDK1.4?
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Michael Matola:
Note that there's a good bit I don't like about what I've done [...]
I wanted to take on Junilu's challenge and also keep the conversation going.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Terry McKee:
I am not sure how to go abou this. I created the test first:
public void testAddition()
{
assertEquals(15.0, calc.calculate("10 + 5"), 0.0);
}
It failed to compile because calculate() doesn't exist. I added the calculate method as follows:
public double calculate(String calculation)
{
return 15.0;
}
I compile both classes, test and get a green light. The problem is how to proceed from here. My thought is I need to parse out the incoming calculation to the calculate method. But I start getting bogged down with the details like:
Parenthesis: "(10 + 5)"
Multiple processes: "5 + 3 + 2"
Combinations of the above processes: "(5 + 3) + 2"
What is the best way to approach this?
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Junilu Lacar:
Now, I know enough about how a calculator works to anticipate that at some point I'll have to implement a Finite State Machine somewhere. The FSM will have at least the following characteristics: [...]
<pre>
public void testAddition() {
calc.in(10.0);
calc.in("+");
calc.in(5.0);
assertEquals(15.0, calc.getResult(), 0.0);
}
</pre>
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Junilu Lacar:
Before any troublemakers object to the introduction of the FSM theory (and I'm not implying anybody in particular, Ilja )
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Junilu Lacar:
I'm not sure if this is a documented refactoring but I'll call it "replace test with polymorphism" for now.
User --> (Input translation) --> (Calculator)