[OCP 17 book] | [OCP 11 book] | [OCA 8 book] [OCP 8 book] [Practice tests book] [Blog] [JavaRanch FAQ] [How To Ask Questions] [Book Promos]
Other Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, TOGAF part 1 and part 2
Michael Bruce Allen wrote:I am learning TDD and using SOLID principals to make a calculator that can take a string "6+8/(2-4*5)" and calculate it properly. So I decided to start with "1+2" and want it to return "3".
I realized really quickly that I do not know what to even look up. I started doing searches and learned about a couple libraries with Classes called Matcher and Pattern, I learned of tokenizer, and I also learned of split. The problem is, I have no idea where to start reading. Would you be so kind in to helping me without telling me the answers?
I really [h]ave no idea how to go about this.
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Michael Bruce Allen wrote:
I just talked to my mentor today and I FINALLY grasped an aspect of TDD. He said just make a test that returns the number 3. So send it a string "3" and literally build a method that returns 3. Then change the input string to 4 and the test will fail. Now make both tests work. Then put different numbers and no number. And so on... Pretty cool. This is big for me, because I just did not understand TDD, I guess, much at all.
Junilu Lacar wrote:
Some things to note about this:
1. TDD is not so much about making very small steps like this but rather keeping your options open to making very small steps like this when you're not quite sure how to proceed. As you get more comfortable with TDD, you'll probably start making bigger steps but the option should always be there to go smaller.
2. The idea is to work backwards from the result rather towards a desired result. I find that this helps you visualize where you want to be while still keeping your options open for how you can get there.
3. You need to have at least a general plan in mind though, especially when the problem and its solution is fairly well-known. I have found that you can easily end up painting yourself in a corner if you just "wing it," especially through TDD.
4. For me, TDD is really more about keeping as many design options open for as long as possible. Tests are used to help drive you towards making better design choices.
Michael Bruce Allen wrote:He also mentioned that I should have one big integration test that fails, and then make smaller tests that knock away at getting little pieces of the big integration test done and finally after the small tests are passing, naturally (or maybe with a bit of work) the big integration will pass as well.
I think this might be what you are saying?
Junilu Lacar wrote:For example, the thing with just returning "3" -- that's a very small step. If you were not doing TDD, you'd probably never do that.
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Stephan van Hulst wrote:One of the biggest eye openers I've had was while reading the following article: http://www.objectmentor.com/resources/articles/xpepisode.htm
...
TDD isn't about writing all the tests for every situation before you do anything else. It is about describing what you expect your code to do, in a language that the testing software understands. I consider tests to be very close to documentation actually, especially if you write them in a clear way.
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Stephan van Hulst wrote:I consider tests to be very close to documentation actually, especially if you write them in a clear way.
Winston Gutkowski wrote:
Junilu Lacar wrote:For example, the thing with just returning "3" -- that's a very small step. If you were not doing TDD, you'd probably never do that.
Hmmm. Not sure I agree there ... but I'm also not sure if what I'm "disagreeing with" is actually what you're saying.
So it's OK how you have done it because you have started to by testing that a single number evaluates to itself, which is really the most "atomic" concept to start with. Now write also an "unit" test which evaluates to 9, like this:
assertEquals(calc.evaluate(new Number(9)), 9.0, 0.00001);
Then make this one pass.
And then go to the next feature by writing an integration test like:
assertEquals (calc.evaluate("1+2"), 3.0, 0.00001);
And then the unit test:
n1 = new Number (1);
n2 = new Number (2);
add = new Addition (n1, n2);
assertEquals (calc.evaluate(add), 3.0, 0.00001);
And then make this pass.
Michael Bruce Allen wrote:I am just unsure what to learn next.
Michael Bruce Allen wrote:
assertEquals(calc.evaluate(new Number(9)), 9.0, 0.00001);
Junilu Lacar wrote:
Michael Bruce Allen wrote:I am just unsure what to learn next.
Besides the basic flow of Red-Green-Refactor, what exactly have you learned so far? This seems to be the biggest hump you have to get past when learning TDD. I ran into this when I was learning and I think so do most folks. After becoming familiar with the mechanics of the technique, you feel lost because now you have to think deeper about design and how the tests are helping you make better design choices.
Think back: have you asked yourself any of the following questions?
1. Is calc.evaluate(whatever) the best API? Is it natural to program to? Is it intuitive? Does it present any difficulties in adding more functionality to the calculator? Does it make testing difficult or easy?
2. Are there other ways I could make this API? What about calc.add(...), calc.multiply(...), calc.subtract(...), etc. ? Would that be a better way to go? Why? Why not?
Michael Bruce Allen wrote:
1. Is calc.evaluate(whatever) the best API? Is it natural to program to? Is it intuitive? Does it present any difficulties in adding more functionality to the calculator? Does it make testing difficult or easy?
2. Are there other ways I could make this API? What about calc.add(...), calc.multiply(...), calc.subtract(...), etc. ? Would that be a better way to go? Why? Why not?
I am not sure that I can truly answer these right now.
Michael Bruce Allen wrote:I have also learned about String subString method and a bit of regex.
Junilu Lacar wrote:
1. You already know that a typical calculator program involves RPN - is that where your calculator design is heading? I don't get a sense that it is.
2. Did you have an overall design in mind when you wrote those tests? If so, how do these tests/methods fit into that design?
3. What about this parser class, is that going to help convert from infix to postfix?
4. How do the parser methods parseCalculationFromString() and getOperand() fit into the overall design? How do you imagine these will be used in your program?
5. Are the tests representative of how the methods are used in the calculator program? Are they good examples?
Michael Bruce Allen wrote:3) probably not. my vision was too small when I made it. I just wanted to solve "1+2"; Errors in user input are not even accounted for yet...
Junilu Lacar wrote:When you're doing TDD, it's important to keep a TODO list. Here's what I might have after writing the code in my last response:
....
Michael Bruce Allen wrote:I also made it so that anyone who reads this would see that it would show on a console as well.
Winston Gutkowski wrote:
...
My first suggestion: Forget TDD, forget SOLID - in fact, forget Java for the moment.
Imagine you have a reasonably intelligent 10-year old child who doesn't know Java. How would you explain to them how to evaluate the string"6+8/(2-4*5)"? In detail.
Specifically:
What do they have to do, precisely, and why? Is there any knowledge they need before they start? (Hint: what's the result of "2-4*5", and why?)
Once you have a set of instructions in English (and not before), then think how to translate them into Java.
And when you do that, think about what might go wrong. For example, suppose you get the string "6?8/(2-4*5)", or (more difficult) "6+8(2-4*5)" - what do you want your program to do?
(Hint: You may find that you have to go through the string more than once)
...
Michael Bruce Allen wrote:
So here is my GUESS at a first test.