开云体育

"self.log = self.log + "testmethod" This seems to be a little smelly to me, because we instrument the production code with functionality for testing purposes." This isn't in production code. The

I like assert-first, too, but it's not a habit yet. Jim- how consistently do you use it? Kent

If the basic operation is simple, I agree. However, the case where I realized just how often I used Starter Test was a polygon reduction algorithm. The OP was frozen by just how complicated the whole

... that I write someNewMethod(); ... and it get's created for me? Intellij IDEA does so, besides a lot ofther amazing stuff. cheers Mittie

A long as you have an interface, easyMock provides you a non-goofy solution even in Java. Not having an interface makes things really going bananas. Mittie

I can easily provide the script. But I need some information: Building and testing is no question, but why committing through the script? Committing can cause all kinds of problems: files not

note: one of my teammates liked to even leave a compile error for the next day, at least as long as we where using VAJ.

I like to start test not with an empty operation. Probably this is because of my bad experiences at university where my professor used to explain every concept either on an empty set or on the space

Today I tried assert-first. It really gives me a little more focus when testing. I like that. A minor drawback is that my code completion does not work as smoothly at before. And I'm really bad at

How do I write my code? Key-by-key ! Isn't that little tiny steps anyways? Hitting the run button in between is almost no difference to me. cheers Mittei

Frank published a paper with an excellent solution for the code examples (to mention only one point). http://www.frankwestphal.de/TestgetriebeneEntwicklung.html That green/red bar thing keeps the

self.log = self.log + "testmethod" This seems to be a little smelly to me, because we instrument the production code with functionality for testing purposes. But with pyhton, I cannot show an

Lately we used "negative tests" to drive the code from constants to calculation. starting with an assert and a constant implementation we write a second assert that shows how the code is expected to

Well, now the problem is, that we're not starting with our goal, but with an intermediate step, that is not motivated directly. This is still because we try to use the Value Object Pattern. This is

Around Monday, February 11, 2002, 8:50:29 PM, Kent Beck wrote: On a related note, Chet and I wrote a thing in Ruby that saves all the files that have changed every time we run the tests. We will

Re: "really working code". I was programming, and running JUnit, as I was writing. It gets a bit mixed up now, because I am revising code mid-stream. I certainly intend to put the last version of the

I believe the interplay of two characters is essential to explaining how dynamic TDD is, but as Steve points out, there's no visual clue that it's going on. Using a different typeface or style would

I've uploaded a version that implements testEquals before testMultiplication. See how you like it. Feel free to send stupid typos to me directly instead of reminding the whole group just how many

There are two schools on writing tests to force you to replace "10" with "amount * rate". The first school I call Triangulation. It predicts that you wait until you are converting 10 USD at 2:1 and

Proactive QA would write application-level tests in preparation for presenting stories to the development group for detailed estimation and implementation. They might also use statistical techniques