Hi,

I'm writing a new book on agile acceptance testing implementation
stories, and I'd like to interview lots of teams as who have implemented
acceptance testing/ATDD/BDD or any of the other alternative names, using
Fit/FitNesse, Concordion, Robot Framework, JBehave, Cucumber or any of
the other tools.

I'm doing this mostly inspired by two things. One was Tom Gilb's rant at
agile testing days last year how agile is crap and nobody is really
doing it, people apparently just lie and talk about their gutfeel.
Another was the InfoQ post about acceptance testing in June that more or
less took the line that the process is something that only a few "elite"
people have been able to implement. I want to contradict both of these
by showing examples of real teams who have been doing it and present how
they are doing the process.

So if your team uses acceptance testing, and you think you have a
successful implementation of the process, I'd like to interview you for
the book. It will only take a short while (45-60 mins) and you'll help a
lot. Please get in touch by sending an e-mail to gojko@....


Best regards,

--
Gojko Adzic
http://gojko.net
Acceptance Testing and TDD workshops http://neuri.co.uk/training

>>Interesting. It's been awhile since I've played with GWT. May I ask for a
>>simple example of what you mean? :-)

TotT: Be an MVP of GUI Testing
http://googletesting.blogspot.com/2009/02/with-all-sport-drug-scandals-of-late.h\
tml

TotT: Testing GWT without GwtTestCase
http://googletesting.blogspot.com/2009/08/tott-testing-gwt-without-gwttest.html

If the links is not clear, below is a simple sketch of why we don´t need do
ask (if you don´t want to)

Change on model:
Model changes->Model tell to your listener(s)(Presenter)->Presenter tell to
view the new value.

Change on view:
View changes->View tell to your listener(s)(Presenter)->Presenter tell to
model the new value.

Makes sense?

--
Abraços,
Josué
http://twitter.com/josuesantos



On Sun, Feb 28, 2010 at 10:32 PM, Franz Allan Valencia See <
franz.see@...> wrote:

>
>
> Interesting. It's been awhile since I've played with GWT. May I ask for a
> simple example of what you mean? :-)
>
> Thanks,
>
> --
> Franz Allan Valencia See | Java Software Engineer
> franz.see@... <franz.see%40gmail.com>
> LinkedIn: http://www.linkedin.com/in/franzsee
> Twitter: http://www.twitter.com/franz_see
>
> On Fri, Feb 26, 2010 at 9:48 PM, Josue Barbosa dos Santos <
> josuesantos@... <josuesantos%40gmail.com>> wrote:
>
> > On Thu, Feb 25, 2010 at 11:35 PM, Franz Allan Valencia See
> > > How about displaying info in the UI?
> > >
> > > i.e. Viewing of personal information in a webapp from a data source.
> And
> > if
> > > there are layering, then each layer would probably have to ask for that
> > > information till the presentation layer gets it.
> > >
> > > WDYT?
> >
> > I think if you use a MVP pattern, for example, the presenter will tell de
> > UI
> > de information. I am working with GWT and this is possible in that
> > framework (and one of others reasons that I like GWT so much.). I think
> > that
> > is not always possible in all views/presentation frameworks.
> >
> >
> >
> > On Fri, Feb 26, 2010 at 10:00 AM, J. B. Rainsberger <
> jbrains762@... <jbrains762%40gmail.com>
> > >wrote:
> >
> > >
> > >
> > > On Thu, Feb 25, 2010 at 11:35 PM, Franz Allan Valencia See
> > > <franz.see@... <franz.see%40gmail.com> <franz.see%40gmail.com>>
> wrote:
> > >
> > > > How about displaying info in the UI?
> > > >
> > > > i.e. Viewing of personal information in a webapp from a data source.
> > And
> > > if
> > > > there are layering, then each layer would probably have to ask for
> that
> > > > information till the presentation layer gets it.
> > > >
> > > > WDYT?
> > >
> > > I'm not sure. My intuition tells me that the presentation object can
> > > always give its pieces to the presentation technology, but I don't
> > > have the energy to crank it all through. I think it would make a good
> > > coding exercise.
> > > --
> > > J. B. (Joe) Rainsberger :: http://www.jbrains.ca ::
> > > http://www.thecodewhisperer.com
> > > Your guide to software craftsmanship
> > > JUnit Recipes: Practical Methods for Programmer Testing
> > > 2005 Gordon Pask Award for contribution Agile Software Practice
> > >
> > >
> >
> >
> >
> > --
>
> > Abraços,
> > Josué
> > http://twitter.com/josuesantos
> >
> >
> > [Non-text portions of this message have been removed]
> >
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
>
> [Non-text portions of this message have been removed]
>
>
>



--
Abraços,
Josué
http://twitter.com/josuesantos


[Non-text portions of this message have been removed]

Hello,
I would be very careful in mixing the concepts of ask/tell and
read/write. You can "ask" in order to write and you can "tell" in
order to read.

About J's consideration :
>> ...This is exactly the example that Franz mentioned. Again, I don't claim
>> it's wise to do, but I wonder what web presentation would look like
>> without asking. I wonder whether the web UI paradigm itself forces us
>> to ask.

This has been my very same doubt for years now. I summarized it in the
question "Should the domain contain the responsibility of representing
itself?"
My answer, lately, is yes, but most UI frameworks answer no and this
is a show stopper for me when I have to accept the use of a UI
framework.

On Mon, Mar 1, 2010 at 2:58 AM, Franz Allan Valencia See
<franz.see@...> wrote:
> This is interesting. Here are probably some factors that affects me having a
> substantial amount of 'ask'.
>
> My style is usually top-down, which means I almost always start with UI. And
> like most systems, I deal with a lot more with 'ask' than 'tell' (aka. a lot
> more read than write, or a lot more R than C.U.D).
>
> Of course, there would be business rules & flows in there and some
> interesting infrastructure, but since most data comes from the data source,
> there's usually quite a bunch of retrieval from the data source before
> something intelligent can be done.
>
> I wonder how others manage this.
>
> Thanks,
>
> --
> Franz Allan Valencia See | Java Software Engineer
> franz.see@...
> LinkedIn: http://www.linkedin.com/in/franzsee
> Twitter: http://www.twitter.com/franz_see
>
> On Fri, Feb 26, 2010 at 9:03 PM, J. B. Rainsberger
<jbrains762@...>wrote:
>
>>
>>
>> ...This is exactly the example that Franz mentioned. Again, I don't claim
>> it's wise to do, but I wonder what web presentation would look like
>> without asking. I wonder whether the web UI paradigm itself forces us
>> to ask.
>> --
>>
>>
>>
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

In some GUI environments, you have to have "ui-known-model" objects
implementing a specific interface, or subclassing something, to work
with specific views in the UI.

Often in such a framework, I would *consider* having that
"ui-known-model" object know about the domain's model object, but not
vice versa. It can get confusing since the "model" objects that work
with the UI are not the "model" objects that we consider to represent
the domain.

On Mon, Mar 1, 2010 at 7:35 AM, Carlo Bottiglieri
<carlo.bottiglieri@...> wrote:
> Hello,
> I would be very careful in mixing the concepts of ask/tell and
> read/write. You can "ask" in order to write and you can "tell" in
> order to read.
>
> About J's consideration :
>>> ...This is exactly the example that Franz mentioned. Again, I don't claim
>>> it's wise to do, but I wonder what web presentation would look like
>>> without asking. I wonder whether the web UI paradigm itself forces us
>>> to ask.
>
> This has been my very same doubt for years now. I summarized it in the
> question "Should the domain contain the responsibility of representing
> itself?"
> My answer, lately, is yes, but most UI frameworks answer no and this
> is a show stopper for me when I have to accept the use of a UI
> framework.
>
> On Mon, Mar 1, 2010 at 2:58 AM, Franz Allan Valencia See
> <franz.see@...> wrote:
>> This is interesting. Here are probably some factors that affects me having a
>> substantial amount of 'ask'.
>>
>> My style is usually top-down, which means I almost always start with UI. And
>> like most systems, I deal with a lot more with 'ask' than 'tell' (aka. a lot
>> more read than write, or a lot more R than C.U.D).
>>
>> Of course, there would be business rules & flows in there and some
>> interesting infrastructure, but since most data comes from the data source,
>> there's usually quite a bunch of retrieval from the data source before
>> something intelligent can be done.
>>
>> I wonder how others manage this.
>>
>> Thanks,
>>
>> --
>> Franz Allan Valencia See | Java Software Engineer
>> franz.see@...
>> LinkedIn: http://www.linkedin.com/in/franzsee
>> Twitter: http://www.twitter.com/franz_see
>>
>> On Fri, Feb 26, 2010 at 9:03 PM, J. B. Rainsberger
<jbrains762@...>wrote:
>>
>>>
>>>
>>> ...This is exactly the example that Franz mentioned. Again, I don't claim
>>> it's wise to do, but I wonder what web presentation would look like
>>> without asking. I wonder whether the web UI paradigm itself forces us
>>> to ask.
>>> --
>>>
>>>
>>>
>>
>>
>> [Non-text portions of this message have been removed]
>>
>>
>>
>> ------------------------------------
>>
>> Yahoo! Groups Links
>>
>>
>>
>>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>



--
C. Keith Ray, IXP Coach, Industrial Logic, Inc.
http://industriallogic.com      866-540-8336 (toll free)
Groove with our Agile Greatest Hits: http://www.industriallogic.com/elearning/
http://agilesolutionspace.blogspot.com/

On Mon, Mar 1, 2010 at 7:35 AM, Carlo Bottiglieri
<carlo.bottiglieri@...> wrote:
>
>
>
> Hello,
> I would be very careful in mixing the concepts of ask/tell and
> read/write. You can "ask" in order to write and you can "tell" in
> order to read.
>

I read that several times and still don't have a clue what you meant
by it. Could you explain?

Sure Adam, I didn't mean it to be as sibylline as it turned out to be.

In the context of UI (but also of persistence and any other activity
which involves in some way exposing the innards of domain objects) you
can for example read a value by telling your domain to fill into
another object (in fact one of the beginning answers to this thread)
and you can write something into the domain by asking the domain for
the value, manipulating it and writing it down in the db (ouch, but
seen it done multiple times).
Thus I don't think that the fact you mostly "read" values is to be
linked with mostly using an "ask" style, I believe the two are
orthogonal : read/write deals with what we do and ask/tell deals with
how we do it (whose responsibility is to read or write, in this case).


On Mon, Mar 1, 2010 at 7:54 PM, Adam Sroka <adam.sroka@...> wrote:
> On Mon, Mar 1, 2010 at 7:35 AM, Carlo Bottiglieri
> <carlo.bottiglieri@...> wrote:
>>
>>
>>
>> Hello,
>> I would be very careful in mixing the concepts of ask/tell and
>> read/write. You can "ask" in order to write and you can "tell" in
>> order to read.
>>
>
> I read that several times and still don't have a clue what you meant
> by it. Could you explain?
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

I probably got it wrong.
Thanks a lot for the clarification!

Sebastian Kübeck

--- In testdrivendevelopment@yahoogroups.com, "J. B. Rainsberger"
<jbrains762@...> wrote:
>
> On Fri, Feb 26, 2010 at 8:28 AM, Sebastian <paymentexpert@...> wrote:
>
> > sorry, this is a little bit off topic but in your presentation "Integration
Tests are a Scam" you said that the number of tests required to cover a certain
amount of code would increase with the factorial of the lines of code under
test.
> > How do you get to this result?
>
> I don't remember saying "the factorial of the lines of code under
> test", because I don't think that's right. I might have said it, but
> if I did, I regret saying it.
>
> The number of tests required to cover a system is combinatoric over
> the code paths in each layer. In other words, if your layers have 2,
> 4, 8, 6, 2, 3, and 7 codepaths respectively, then you need
> approximately 2*4*8*6*2*3*7 tests.
>
> Alternately, we can estimate the number of tests as O(c^n) where we
> have on average c codepaths per layer and n layers.
> --
> J. B. (Joe) Rainsberger :: http://www.jbrains.ca ::
> http://www.thecodewhisperer.com
> Your guide to software craftsmanship
> JUnit Recipes: Practical Methods for Programmer Testing
> 2005 Gordon Pask Award for contribution Agile Software Practice
>

As far as I understand it, the number of tests required is related to the state
space. The more possible states, the more tests you need to capture them.
I don't know if there is a relation between the state space and number of
objects.

Sebastian Kübeck

--- In testdrivendevelopment@yahoogroups.com, Adam Sroka <adam.sroka@...> wrote:
>
> I don't know about lines of code, but it makes sense if we look at the
> number of unique objects. The upper bound would be O(n!) combinations if the
> object graph were strongly connected (i.e. each object has a direct
> relationship to every other object in the system.) Minimally no object would
> have a direct relationship to more than a single other object. That would be
> O(n). The average is somewhere between those (I would estimate about O(n^2)
> but I haven't tried to prove it.) Remember that relationships between
> objects are directional.
>
> On Sun, Feb 28, 2010 at 5:34 PM, J. B. Rainsberger <jbrains762@...>wrote:
>
> >
> >
> > On Fri, Feb 26, 2010 at 8:28 AM, Sebastian
<paymentexpert@...<paymentexpert%40yahoo.de>>
> > wrote:
> >
> > > sorry, this is a little bit off topic but in your presentation
> > "Integration Tests are a Scam" you said that the number of tests required to
> > cover a certain amount of code would increase with the factorial of the
> > lines of code under test.
> > > How do you get to this result?
> >
> > I don't remember saying "the factorial of the lines of code under
> > test", because I don't think that's right. I might have said it, but
> > if I did, I regret saying it.
> >
> > The number of tests required to cover a system is combinatoric over
> > the code paths in each layer. In other words, if your layers have 2,
> > 4, 8, 6, 2, 3, and 7 codepaths respectively, then you need
> > approximately 2*4*8*6*2*3*7 tests.
> >
> > Alternately, we can estimate the number of tests as O(c^n) where we
> > have on average c codepaths per layer and n layers.
> >
> > --
> > J. B. (Joe) Rainsberger :: http://www.jbrains.ca ::
> > http://www.thecodewhisperer.com
> > Your guide to software craftsmanship
> > JUnit Recipes: Practical Methods for Programmer Testing
> > 2005 Gordon Pask Award for contribution Agile Software Practice
> >
> >
>
>
> [Non-text portions of this message have been removed]
>

I think I see what you are saying. I'm not sure how to relate it to TDA. The
way I understand TDA is that as your collaborator I should not ask you a
question /and then/ tell you what to do based on your answer. Because, if I
did that I would be breaking your encapsulation.

I have never understood TDA to mean that I can't issue queries. Only that I
should let my collaborators handle their own business.

On Mon, Mar 1, 2010 at 11:44 AM, Carlo Bottiglieri <
carlo.bottiglieri@...> wrote:

>
>
> Sure Adam, I didn't mean it to be as sibylline as it turned out to be.
>
> In the context of UI (but also of persistence and any other activity
> which involves in some way exposing the innards of domain objects) you
> can for example read a value by telling your domain to fill into
> another object (in fact one of the beginning answers to this thread)
> and you can write something into the domain by asking the domain for
> the value, manipulating it and writing it down in the db (ouch, but
> seen it done multiple times).
> Thus I don't think that the fact you mostly "read" values is to be
> linked with mostly using an "ask" style, I believe the two are
> orthogonal : read/write deals with what we do and ask/tell deals with
> how we do it (whose responsibility is to read or write, in this case).
>
>
> On Mon, Mar 1, 2010 at 7:54 PM, Adam Sroka
<adam.sroka@...<adam.sroka%40gmail.com>>
> wrote:
> > On Mon, Mar 1, 2010 at 7:35 AM, Carlo Bottiglieri
> > <carlo.bottiglieri@... <carlo.bottiglieri%40gmail.com>> wrote:
> >>
> >>
> >>
> >> Hello,
> >> I would be very careful in mixing the concepts of ask/tell and
> >> read/write. You can "ask" in order to write and you can "tell" in
> >> order to read.
> >>
> >
> > I read that several times and still don't have a clue what you meant
> > by it. Could you explain?
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
>
>


[Non-text portions of this message have been removed]

Yes, exactly, that's why I mention the allocation of responsibilities
and how it has nothing to do with what we are doing (read/write), but
rather who is doing it.

On Mon, Mar 1, 2010 at 9:53 PM, Adam Sroka <adam.sroka@...> wrote:
> I think I see what you are saying. I'm not sure how to relate it to TDA. The
> way I understand TDA is that as your collaborator I should not ask you a
> question /and then/ tell you what to do based on your answer. Because, if I
> did that I would be breaking your encapsulation.
>
> I have never understood TDA to mean that I can't issue queries. Only that I
> should let my collaborators handle their own business.
>
> On Mon, Mar 1, 2010 at 11:44 AM, Carlo Bottiglieri <
> carlo.bottiglieri@...> wrote:
>
>>
>>
>> Sure Adam, I didn't mean it to be as sibylline as it turned out to be.
>>
>> In the context of UI (but also of persistence and any other activity
>> which involves in some way exposing the innards of domain objects) you
>> can for example read a value by telling your domain to fill into
>> another object (in fact one of the beginning answers to this thread)
>> and you can write something into the domain by asking the domain for
>> the value, manipulating it and writing it down in the db (ouch, but
>> seen it done multiple times).
>> Thus I don't think that the fact you mostly "read" values is to be
>> linked with mostly using an "ask" style, I believe the two are
>> orthogonal : read/write deals with what we do and ask/tell deals with
>> how we do it (whose responsibility is to read or write, in this case).
>>
>>
>> On Mon, Mar 1, 2010 at 7:54 PM, Adam Sroka
<adam.sroka@...<adam.sroka%40gmail.com>>
>> wrote:
>> > On Mon, Mar 1, 2010 at 7:35 AM, Carlo Bottiglieri
>> > <carlo.bottiglieri@... <carlo.bottiglieri%40gmail.com>> wrote:
>> >>
>> >>
>> >>
>> >> Hello,
>> >> I would be very careful in mixing the concepts of ask/tell and
>> >> read/write. You can "ask" in order to write and you can "tell" in
>> >> order to read.
>> >>
>> >
>> > I read that several times and still don't have a clue what you meant
>> > by it. Could you explain?
>> >
>> >
>> > ------------------------------------
>> >
>> > Yahoo! Groups Links
>> >
>> >
>> >
>> >
>>
>>
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

I am talking about the number of relationships between objects. If I have to
write a test for each possible combination of interacting objects then there
are a lot of tests to write. If I focus my tests only on a pair of objects
which collaborate directly with one another then I have to write many, many
fewer tests. That is what I understood Joe to be saying.

It is a problem of combinatorics. For any given system it is possible to
describe the result mathematically, but generalizing it is difficult because
object oriented systems have complex graphs of relationships (Including
bi-directional ones, circular ones, self-referential ones, etc.) It is
probable that any precise generalization will devolve to pseudo-math (In
fact, we are probably there already ;-)

On Mon, Mar 1, 2010 at 2:17 AM, Sebastian <paymentexpert@...> wrote:

>
>
> As far as I understand it, the number of tests required is related to the
> state space. The more possible states, the more tests you need to capture
> them.
> I don't know if there is a relation between the state space and number of
> objects.
>
> Sebastian Kübeck
>
>
> --- In
testdrivendevelopment@yahoogroups.com<testdrivendevelopment%40yahoogroups.com>,
> Adam Sroka <adam.sroka@...> wrote:
> >
> > I don't know about lines of code, but it makes sense if we look at the
> > number of unique objects. The upper bound would be O(n!) combinations if
> the
> > object graph were strongly connected (i.e. each object has a direct
> > relationship to every other object in the system.) Minimally no object
> would
> > have a direct relationship to more than a single other object. That would
> be
> > O(n). The average is somewhere between those (I would estimate about
> O(n^2)
> > but I haven't tried to prove it.) Remember that relationships between
> > objects are directional.
> >
> > On Sun, Feb 28, 2010 at 5:34 PM, J. B. Rainsberger <jbrains762@
> ...>wrote:
> >
> > >
> > >
> > > On Fri, Feb 26, 2010 at 8:28 AM, Sebastian <paymentexpert@
> ...<paymentexpert%40yahoo.de>>
>
> > > wrote:
> > >
> > > > sorry, this is a little bit off topic but in your presentation
> > > "Integration Tests are a Scam" you said that the number of tests
> required to
> > > cover a certain amount of code would increase with the factorial of the
> > > lines of code under test.
> > > > How do you get to this result?
> > >
> > > I don't remember saying "the factorial of the lines of code under
> > > test", because I don't think that's right. I might have said it, but
> > > if I did, I regret saying it.
> > >
> > > The number of tests required to cover a system is combinatoric over
> > > the code paths in each layer. In other words, if your layers have 2,
> > > 4, 8, 6, 2, 3, and 7 codepaths respectively, then you need
> > > approximately 2*4*8*6*2*3*7 tests.
> > >
> > > Alternately, we can estimate the number of tests as O(c^n) where we
> > > have on average c codepaths per layer and n layers.
> > >
> > > --
> > > J. B. (Joe) Rainsberger :: http://www.jbrains.ca ::
> > > http://www.thecodewhisperer.com
> > > Your guide to software craftsmanship
> > > JUnit Recipes: Practical Methods for Programmer Testing
> > > 2005 Gordon Pask Award for contribution Agile Software Practice
> > >
> > >
> >
> >
> > [Non-text portions of this message have been removed]
> >
>
>
>


[Non-text portions of this message have been removed]

On Sun, Feb 28, 2010 at 8:51 PM, Joshua Kerievsky
<jlk@...> wrote:

> On Sun, Feb 28, 2010 at 5:41 PM, J. B. Rainsberger
<jbrains762@...>wrote:
>
> > I merely shared what I do; I didn't judge what you did. I use HSQLDB
> > when test doubles aren't yet convenient.
>
> I'm not judging, just voicing confusion about your statement. HSQLDB
> provides fake DB behavior without one lifting a finger (i.e. writing test
> code). What could be more convenient than that?

Aha. I didn't mean to say that HSQLDB was or was not convenient. I
agree it's convenient. When I use HSQLDB, though, it allows me to
duplicate code more easily in the database implementations of my
Repository interfaces. This happens because the tests for those
implementations execute quickly, which defers the pain of the
duplication, both in the tests and in the production code. Knowing I
have this blindspot, I tend to use HSQLDB to rescue legacy database
access, eventually replacing it with a small number (20) of tests that
have to talk directly to the production RDBMS. The rest execute in
memory.

I hope that clears it up.
--
J. B. (Joe) Rainsberger :: http://www.jbrains.ca ::
http://www.thecodewhisperer.com
Your guide to software craftsmanship
JUnit Recipes: Practical Methods for Programmer Testing
2005 Gordon Pask Award for contribution Agile Software Practice

On Mon, Mar 1, 2010 at 1:58 PM, J. B. Rainsberger <jbrains762@...>wrote:

> Aha. I didn't mean to say that HSQLDB was or was not convenient. I
> agree it's convenient. When I use HSQLDB, though, it allows me to
> duplicate code more easily in the database implementations of my
> Repository interfaces. This happens because the tests for those
> implementations execute quickly, which defers the pain of the
> duplication, both in the tests and in the production code. Knowing I
> have this blindspot, I tend to use HSQLDB to rescue legacy database
> access, eventually replacing it with a small number (20) of tests that
> have to talk directly to the production RDBMS. The rest execute in
> memory.
>
> I hope that clears it up.
>

I think this points out a large issue which is that fakes can sometimes hide
larger design issues.  -- best, jk


[Non-text portions of this message have been removed]

> I think this points out a large issue which is that fakes can sometimes hide
> larger design issues.  -- best, jk
>
>
I think so, but fakes probably the most straight forward way to built
test cases around the system with design isseus, then we can refactor
to a better design.

Or you will think this usually not the best approach to improve the
system? May be we should clean up the dependence first?

On 2 Mar 2010, at 05:40, Joshua Kerievsky wrote:
> On Mon, Mar 1, 2010 at 1:58 PM, J. B. Rainsberger <jbrains762@...>wrote:
>> Aha. I didn't mean to say that HSQLDB was or was not convenient. I
>> [...]
>> have to talk directly to the production RDBMS. The rest execute in
>> memory.
>
> I think this points out a large issue which is that fakes can sometimes hide
> larger design issues.  -- best, jk

Or, that mocks are most useful when used to guide design, rather than optimise
test performance--and that no-one should write tests with mocks without (first)
also writing higher-level tests.

S.

Steve Freeman

http://www.m3p.co.uk/blog
http://www.growing-object-oriented-software.com

On Mon, Mar 1, 2010 at 10:40 PM, Joshua Kerievsky
<jlk@...> wrote:

> I think this points out a large issue which is that fakes can sometimes hide
> larger design issues. -- best, jk

Indeed what I meant.
--
J. B. (Joe) Rainsberger :: http://www.jbrains.ca ::
http://www.thecodewhisperer.com
Your guide to software craftsmanship
JUnit Recipes: Practical Methods for Programmer Testing
2005 Gordon Pask Award for contribution Agile Software Practice

On Tue, Mar 2, 2010 at 12:30 AM, Steve Freeman <smgfreeman@...> wrote:
>
>
>
> On 2 Mar 2010, at 05:40, Joshua Kerievsky wrote:
> > On Mon, Mar 1, 2010 at 1:58 PM, J. B. Rainsberger
<jbrains762@...>wrote:
> >> Aha. I didn't mean to say that HSQLDB was or was not convenient. I
> >> [...]
> >> have to talk directly to the production RDBMS. The rest execute in
> >> memory.
> >
> > I think this points out a large issue which is that fakes can sometimes hide
> > larger design issues. -- best, jk
>
> Or, that mocks are most useful when used to guide design, rather than optimise
test performance--and that no-one should write tests with mocks without (first)
also writing higher-level tests.
>

Hopefully it is not controversial to say that neither mocks nor fakes
are a panacea.

Mocks and stubs keep me focused on a single module. That is good when
I want to focus, but if I only ever do that then my view of the system
is fairly myopic.

Fakes have behavior that is richer than a simple stub. This makes it
easier to test more coupled code. Which also means that fakes are more
tolerant of a highly coupled design.

Using either approach (or any single approach) exclusively is likely
to lead to poor design.

Hi,

I currently work for a company trying hard to become agile.

TDD is not being done and it is hoped it will be over time.

Our Scrum Master has told the development team to design upfront for each
story and produce sequence diagrams, uml, etc.

Does this not impair the TDD process? Its when you sit down and write that
first test case that the class under test starts to come together.

I cannot see how I would produce the same result with upfront design and
TDD.

Any thoughts?

R


[Non-text portions of this message have been removed]

Hi,

Has anyone used Ranorex? Is it a tool that can be assimilated easily/well
into a good agile'esque continual integration pipeline?

Thank you,

Nick.


[Non-text portions of this message have been removed]

On Tue, Mar 2, 2010 at 11:15 PM, Rakesh <rakesh.mailgroups@...> wrote:
>
>
>
> Hi,
>
> I currently work for a company trying hard to become agile.
>
> TDD is not being done and it is hoped it will be over time.
>
> Our Scrum Master has told the development team to design upfront for each
> story and produce sequence diagrams, uml, etc.
>

Scrummasters don't tell team members what artifacts to produce or how
to accomplish design. This person is not acting in the role of
Scrummaster. Training is needed.

> Does this not impair the TDD process? Its when you sit down and write that
> first test case that the class under test starts to come together.
>

Creating UML diagrams is not part of TDD, but it is not an impediment
to it per se. Everyone goes through some process when considering how
they are going to solve a particular problem. Some talk through it,
some create todo lists, some use diagrams or other design artifacts.

Write a test as soon as you know what test to write. Use whatever
means you feel appropriate to figure out what that test is.

> I cannot see how I would produce the same result with upfront design and
> TDD.
>

The trick is to do as little up front design as you need to get you to
the point where you feel confident in writing that first test, and
then to listen to where the tests lead you. When you have solved the
problem you set out to solve you may have done it very differently
than you initially imagined, but that doesn't mean that the imagining
was a wasted exercise.

Rakesh,

On one project I had to produce a detailed design. I actually TDD'd the code and
then created the diagrams from that! It went quite quickly actually, and I had a
design that I knew would work.

But in general I don't think some design up-front hurts. Just not too much, and
be prepared to refactor it.

Also, you don't mention how big the project is. The bigger it is, the more need
there is for some agreement of the links and relationships between the pieces.

John D.


-----Original Message-----
From: testdrivendevelopment@yahoogroups.com
[mailto:testdrivendevelopment@yahoogroups.com] On Behalf Of Rakesh
Sent: 03 March 2010 08:15
To: testdrivendevelopment@yahoogroups.com
Subject: [TDD] TDD and modelling

Hi,

I currently work for a company trying hard to become agile.

TDD is not being done and it is hoped it will be over time.

Our Scrum Master has told the development team to design upfront for each
story and produce sequence diagrams, uml, etc.

Does this not impair the TDD process? Its when you sit down and write that
first test case that the class under test starts to come together.

I cannot see how I would produce the same result with upfront design and
TDD.

Any thoughts?

R


[Non-text portions of this message have been removed]



------------------------------------

Yahoo! Groups Links

On Wed, Mar 3, 2010 at 12:15 AM, Rakesh <rakesh.mailgroups@...> wrote:

> Our Scrum Master has told the development team to design upfront for each
> story and produce sequence diagrams, uml, etc.

I agree with Adam. Your "Scrum Master" needs to learn that telling you
how to do your job does not fall within his role as Scrum Master. Even
so, we don't need to fix that problem straight away.

> Does this not impair the TDD process? Its when you sit down and write that
> first test case that the class under test starts to come together.
>
> I cannot see how I would produce the same result with upfront design and
> TDD.

You can start with test-first programming. In test-first programming,
we draw a design up front, then use tests to help us type it in
correctly. Often, this means we have to add details to our designs to
make it easier for us to check the behavior of methods and classes. We
do that, but we don't like it. Often, we find difficulties writing
tests because when we drew our design diagrams, we did not take
testing into account. We change the design to make it easier to test,
and update the diagrams if we must.

This feels slow, but during the time, you will learn which kinds of
up-front design decisions make code difficult to test, and start
avoiding them. You will also learn how writing tests first leads to
designs with lower coupling (remove duplication!) and higher cohesion
(fix bad names!). With this experience, over time, you will feel more
and more comfortable doing less and less design up front. At the same
time, you will show your Scrum Master that less design up front
doesn't mean "hacking" or "umprofessional work". Eventually, you can
probably generate the design diagrams from your actual code and your
Scrum Master won't know the difference.

Do you think this might help you?
--
J. B. (Joe) Rainsberger :: http://www.jbrains.ca ::
http://www.thecodewhisperer.com
Your guide to software craftsmanship
JUnit Recipes: Practical Methods for Programmer Testing
2005 Gordon Pask Award for contribution Agile Software Practice

--- In testdrivendevelopment@yahoogroups.com, Rakesh <rakesh.mailgroups@...>
wrote:
>
> Hi,
>
> I currently work for a company trying hard to become agile.
>
> TDD is not being done and it is hoped it will be over time.
>
> Our Scrum Master has told the development team to design upfront for each
> story and produce sequence diagrams, uml, etc.
>
> Does this not impair the TDD process? Its when you sit down and write that
> first test case that the class under test starts to come together.
>
> I cannot see how I would produce the same result with upfront design and
> TDD.
>
> Any thoughts?
>
> R


> Does this not impair the TDD process?


For what it's worth I think the uml diagrams can be helpful for getting people
on the same page with regard to how the model for the software is being thought
about.  Though that work doesn't need to expressed in UML, in my experience UML
is common enough that it's a convenient choice.  Also you can think about
testabiliy while doing your up-front design.

Question, why do you think it impairs the TDD process?


Cheers,
Aeden

--- In testdrivendevelopment@yahoogroups.com, Adam Sroka <adam.sroka@...> wrote:
>
> On Tue, Mar 2, 2010 at 11:15 PM, Rakesh <rakesh.mailgroups@...> wrote:
> >
> > TDD is not being done and it is hoped it will be over time.
> >
> > Our Scrum Master has told the development team to design upfront for each
> > story and produce sequence diagrams, uml, etc.
> >

Perhaps another way to look at it is that the team members should do some just
enough modeling on a just in time basis when it makes sense to do so.  This
might mean you do some initial requirements and architecture envisioning at the
beginning of the project, it might mean that you do some iteration/sprint
modeling at the beginning of an iteration/sprint as part of your
iteration/sprint planning, and it might mean that you do some model storming
throughout the iteration/sprint.  See
http://www.agilemodeling.com/essays/amdd.htm for how modeling and TDD fit
together.


>
> > Does this not impair the TDD process? Its when you sit down and write that
> > first test case that the class under test starts to come together.
> >
>
> Creating UML diagrams is not part of TDD, but it is not an impediment
> to it per se.

Actually, it's not just about UML, there are many non-UML models you might want
to consider.  User stories, for example, aren't UML.


>
> > I cannot see how I would produce the same result with upfront design and
> > TDD.

The vast majority of agile teams do some sort of up-front modeling, see
http://www.ambysoft.com/surveys/projectInitiation2009.html .


- Scott

If you are in the Detroit, MI area next Saturday (3/13) ... there are two 2.5
hour hands-on Java workshops (
http://mostlyfree.org/sessions.html#hands-on-technology ).

-Context Follows -

2010 MI: Agile and Beyond features highly experienced, mostly-regional
practitioners in a mix of keynote presentations, panel discussions, and hands-on
workshops. Our conference theme is "THE FORESIGHT TO 'IMAGINE' BIG … THE INSIGHT
TO 'TWEAK' SMALL", using inspiration from Henry Ford for his ability to build
cars in far less time at higher quality than previously accomplished. The
conference explores how `Agile' practices help us make a similar leap in
delivering quality software.

There is something for everyone, from those that have just begun to explore
`Agile' development to those with many years of experience; from Developers to
Managers to Business Analysts to QA/QC specialists. Conference fees are
comparable to a fancy dinner out for a full day's worth of thought-provoking,
energizing content. Transferable Registration runs through March 10, so be sure
to sign up now. If you have further questions, contact one of our volunteers at
http://MostlyFree.org/team.html

Hi Rakesh,

Could I ask how comfortable you and your team are at doing TDD?

From my recent experience of learning and adopting TDD I had similar
concerns to you. It turned out that the biggest impediment to adopting TDD
was actually programmer capability. I didn't really know how do to TDD,
because I'd never been taught.

To remedy this, I started practicing away from the pressures of work
projects. I read a lot and used my own personal projects to get started. If
I wanted to make a change to any of my personal projects I wrote tests
first. It was slow, difficult and frustrating. I went and took a course and
asked a lot of questions. Things got a little easier. I continued to
practice.

The first time I used TDD (rather than test-first) exclusively for an actual
line of production code was a great feeling. It was for a legacy system, so
it had no unit tests. I did an "incremental rewrite" to get started:
Replacing a single line of untested Production code with my freshly TDD'ed
code and tests.

If you can get a group of your team together to practice away from your
current project, then that would be great. If you can get yourself and your
team to practice away from work altogether, also great. If you can get some
training, do it! A combination of these things paid off for me.



Thanks,
James.



On Wed, Mar 3, 2010 at 6:15 PM, Rakesh <rakesh.mailgroups@...> wrote:

> Hi,
>
> I currently work for a company trying hard to become agile.
>
> TDD is not being done and it is hoped it will be over time.
>
> Our Scrum Master has told the development team to design upfront for each
> story and produce sequence diagrams, uml, etc.
>
> Does this not impair the TDD process? Its when you sit down and write that
> first test case that the class under test starts to come together.
>
> I cannot see how I would produce the same result with upfront design and
> TDD.
>
> Any thoughts?
>
> R
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>


[Non-text portions of this message have been removed]

Em 6/3/2010 20:41, bevelededges escreveu:
>
>
>
> --- In testdrivendevelopment@yahoogroups.com
> <mailto:testdrivendevelopment%40yahoogroups.com>, Rakesh
> <rakesh.mailgroups@...> wrote:
> >
> > Hi,
> >
> > I currently work for a company trying hard to become agile.
> >
> > TDD is not being done and it is hoped it will be over time.
> >
> > Our Scrum Master has told the development team to design upfront for
> each
> > story and produce sequence diagrams, uml, etc.
> >
> > Does this not impair the TDD process? Its when you sit down and
> write that
> > first test case that the class under test starts to come together.
> >
> > I cannot see how I would produce the same result with upfront design and
> > TDD.
> >
> > Any thoughts?
> >
> > R
>
> > Does this not impair the TDD process?
>
> For what it's worth I think the uml diagrams can be helpful for
> getting people on the same page with regard to how the model for the
> software is being thought about. Though that work doesn't need to
> expressed in UML, in my experience UML is common enough that it's a
> convenient choice. Also you can think about testabiliy while doing
> your up-front design.
>
> Question, why do you think it impairs the TDD process?
>

TDD is more related to design than it's related to testing, so if you
upfront design in a very fine-grained fashion (e.g. class diagrams) a
huge benefit of TDD is lost.

In TDD by Exemple Kent Beck states:

"TDD has some technical implications such as following:
- We must design organically, with running code providing feedback
between decision."

> Cheers,
> Aeden
>
>



[Non-text portions of this message have been removed]

On Tue, Mar 9, 2010 at 1:54 PM, Ricardo Mayerhofer
<ricardo.ekm.listas@...> wrote:
>
>
>
> Em 6/3/2010 20:41, bevelededges escreveu:
> >
> >
> >
> > --- In testdrivendevelopment@yahoogroups.com
> > <mailto:testdrivendevelopment%40yahoogroups.com>, Rakesh
>
> > <rakesh.mailgroups@...> wrote:
> > >
> > > Hi,
> > >
> > > I currently work for a company trying hard to become agile.
> > >
> > > TDD is not being done and it is hoped it will be over time.
> > >
> > > Our Scrum Master has told the development team to design upfront for
> > each
> > > story and produce sequence diagrams, uml, etc.
> > >
> > > Does this not impair the TDD process? Its when you sit down and
> > write that
> > > first test case that the class under test starts to come together.
> > >
> > > I cannot see how I would produce the same result with upfront design and
> > > TDD.
> > >
> > > Any thoughts?
> > >
> > > R
> >
> > > Does this not impair the TDD process?
> >
> > For what it's worth I think the uml diagrams can be helpful for
> > getting people on the same page with regard to how the model for the
> > software is being thought about. Though that work doesn't need to
> > expressed in UML, in my experience UML is common enough that it's a
> > convenient choice. Also you can think about testabiliy while doing
> > your up-front design.
> >
> > Question, why do you think it impairs the TDD process?
> >
>
> TDD is more related to design than it's related to testing, so if you
> upfront design in a very fine-grained fashion (e.g. class diagrams) a
> huge benefit of TDD is lost.
>

It's roughly equally about both. I would say that TDD is about being
able to make decisions based on fairly deterministic feedback. The
making decisions bit is about design, but the deterministic feedback
bit is about testing. So, it's both.

Class diagrams do not imply too fine-grained of a design. They don't
really give feedback either. They can be useful for communicating
intent at a slightly higher level than code.

> In TDD by Exemple Kent Beck states:
>
> "TDD has some technical implications such as following:
> - We must design organically, with running code providing feedback
> between decision."
>

Yep, but I wouldn't say that UML must run afoul of this. Certainly if
the UML represents some kind of contract that the Dev Manager (nee
Scrum Master) is expecting us to hold to then we are in trouble. This
smells like command-and-control reinforced through document-centric
processes. It is antithetical to Agile, but not to TDD per se.

For example, I assume that the manager expects the UML to reflect my
design. If TDD is how I do design then I would have to do that first
and then create the UML. There is no inherent conflict until the thing
I created has to change. TDD isn't about responding to change per se,
but Agile is.

You may want to check this thread:
http://groups.yahoo.com/group/scrumdevelopment/message/45852

Em 3/3/2010 04:15, Rakesh escreveu:
>
> Hi,
>
> I currently work for a company trying hard to become agile.
>
> TDD is not being done and it is hoped it will be over time.
>
> Our Scrum Master has told the development team to design upfront for each
> story and produce sequence diagrams, uml, etc.
>
> Does this not impair the TDD process? Its when you sit down and write that
> first test case that the class under test starts to come together.
>
> I cannot see how I would produce the same result with upfront design and
> TDD.
>
> Any thoughts?
>
> R
>
> [Non-text portions of this message have been removed]
>
>



[Non-text portions of this message have been removed]

--- In testdrivendevelopment@yahoogroups.com, Rakesh <rakesh.mailgroups@...>
wrote:
>
>
> Our Scrum Master has told the development team to design upfront for each
> story and produce sequence diagrams, uml, etc.
>
> Does this not impair the TDD process? Its when you sit down and write that
> first test case that the class under test starts to come together.
>
> I cannot see how I would produce the same result with upfront design and
> TDD.

visit
http://www.agilemodeling.com/

http://tech.groups.yahoo.com/group/agilemodeling/