开云体育

Personally I don't go outside-in or inside-out, but I use one of two heuristics that work well for me: 1) What is the customer trying to accomplish? How would I know if it did that? 2) What is the

I've seen Ward Cunningham and Kent Beck, both widely regarded as the inventors of TDD, code, and neither of them followed strict "outside-in" semantics. It must at least be possible that you could

Eb, Do you mean the outside object may need to provide additional parameters to the inside object? Keith's example doesn't seem very outside-in to me, in the sense that the inside object seems to

Ron - Keith gave an example of such a scenario. The outside object doesn't necessarily meet the needs of the inside object. I personally, rarely get expectations right (being complete) the first -

If "outside" is GUI/user and "inside" is using a framework or database, then there can be a mis-match, when you find out the database needs info not yet provided by the GUI/user, or that the framework

Eb, Really? You developed some outside object, and then went to develop an inside object, and it didn't meet the needs of the object, already existing, that was calling it?? How did that

Ok. But I've experienced that developing outside in also.

Simply because you are assuming, as you develop your "inside" objects, that they will provide the right services to the "outside" objects that you will develop later. They might, or they might not,

How so? -- blog: http://eikonne.wordpress.com twitter: @eikonne

Eb wrote: Your probability increases that you develop the wrong thing. :) On the original point, if your guards are mostly about null, then you can annotate your stuff with @Nonnull (or similar if

I believe it was this advice (from Ron) that I read many, many years ago (fairly sure it was on this list too) that led me to drop doing defensive coding and I've never looked back. Not only does it

Exactly, bad habit! LOL. Thanks Adam.

Thanks Ron. It sounds like you test/develop outside in. Is my inference wrong? Curious how if this changes if one develops inside out. Probably the statement would that be we will be writing tests

Those i.e.s should have been e.g.s and by "customer doesn't expect an error" I meant customer expects not to see an error... That's what I get for writing emails at the bar

If a customer expects an error (i.e. I put in the wrong number, oops) test for it. If a customer doesn't expect an error (i.e. WTF does "500 server error" mean, and how do I get this job done?) test

Eb, Generally speaking, I do not check arguments for correctness. If I am building the entire app via TDD, the code that calls the method is already tested, and therefore in fact calls with correct

Lior - Sure. Eb

What is appropriate for your team depends on your culture and the requirements around how semantics are communicated between developers in your team, developers in other teams consuming your work, QA,

Eb, All these behaviors can be valid. The actual question in my opinion, is what would you expect your production code to do? Should it validate the inputs? What should it do if "bad" inputs are

Hi Edwin - So what's your opinion on what to actually do? What would the tests look like? Thanks. Ebenezer -- blog: http://eikonne.wordpress.com twitter: @eikonne