Re: Unit tests and parameter validation

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 essence of the problem that I don't yet understand? How
would I learn about that?

I pick one of those two, write a test for it, and see where it leads me.
Then, after a reasonable amount of time -- from a few minutes to maybe an
hour -- I take a break and talk with my pair about how we want to go at it
next. I repeat that process until it's time for a meeting or a beer.

On Friday, October 18, 2013, Adam Sroka wrote:

> 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 create a simple
> design without doing that.
>
> On Friday, October 18, 2013, Michal Svoboda wrote:
>
>> **
>>
>>
>> Eb wrote:
>> > Curious how if this changes if one develops inside out.
>>
>> 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 your language
>> supports it). This then makes the contract more like a strong type
>> system and violations can be likely caught by static analysis tools.
>>
>> Michal
>>  
>>
>