I guess this isn't strictly a Ruby question, but it's about stuff that comes up on the ML quite a bit, so I thought I'd mention it.
I've heard a lot of people saying great things about test-first programming (on the ML). I've heard a lot of people saying great things about bottom-up programming (off the ML). They both seem to have their merits, but they seem totally opposed to each other. Am I wrong in that?
Are there people using both? Or am I confusing "test-first" with "test-driven" development? (I thought they were the same thing.)
In any case, it seems that if you choose one, you must eschew the other (consciously or otherwise). Assuming it is consciously, how do you reconcile the apparent benefits of the methodology you don't use with the fact that you don't use it?
I guess this isn't strictly a Ruby question, but it's about stuff that comes up on the ML quite a bit, so I thought I'd mention it.
I've heard a lot of people saying great things about test-first programming (on the ML). I've heard a lot of people saying great things about bottom-up programming (off the ML). They both seem to have their merits, but they seem totally opposed to each other. Am I wrong in that?
Are there people using both? Or am I confusing "test-first" with "test-driven" development? (I thought they were the same thing.)
In any case, it seems that if you choose one, you must eschew the other (consciously or otherwise). Assuming it is consciously, how do you reconcile the apparent benefits of the methodology you don't use with the fact that you don't use it?
I mean, I hate to ask it, but...
"Which is better??"
Chris
tdd or 'test first' has nothing to do with 'bottom up' or 'top down', you can do ttd with either. tdd has a lot to do with how you write the code, ie write the tests before the code, get the tests to pass and then write more tests / code. 'top down' or 'bottom up' is more about the order that you write / develop the code.
if you start your design top down you can use tdd to drive the coding. remember you can fake the lower level elements as stubs until you get round to coding them.
if you start bottom up you can use tdd in the same way except that you don't have stubs to fake the lower levels you have harnesses to fake the higher levels.
there is absolutly no conflict between tdd and 'top down' / 'bottom up'
remember 'top down' and 'bottom up' are DESIGN methodologies and tdd is test driven DEVELOPMENT (to quote from the spine of beck's book on the subject).
"Peter Hickman" <peter@semantico.com> schrieb im Newsbeitrag
news:4107ADE9.8080906@semantico.com...
tdd or 'test first' has nothing to do with 'bottom up' or 'top down',
you can do ttd with either. tdd has a lot to do with how you write the
code, ie write the tests before the code, get the tests to pass and then
write more tests / code. 'top down' or 'bottom up' is more about the
order that you write / develop the code.
if you start your design top down you can use tdd to drive the coding.
remember you can fake the lower level elements as stubs until you get
round to coding them.
if you start bottom up you can use tdd in the same way except that you
don't have stubs to fake the lower levels you have harnesses to fake the
higher levels.
there is absolutly no conflict between tdd and 'top down' / 'bottom up'
remember 'top down' and 'bottom up' are DESIGN methodologies and tdd is
test driven DEVELOPMENT (to quote from the spine of beck's book on the
subject).
I was going to say the same. Two additional remarks: as you mention
implicitely, using bottom-up with tdd might be a bit easier / faster
because you save yourself all those lower level stubs that you need with
top-down and tdd.
The choice between top-down and bottom-up very much depends on the type of
software that you are creating: roughly speaking bottom-up usually results
in more reuse and is better suited to libraries while top-down is better
for application development because breaking down complex tasks into
smaller tasks is the simplest way to get from requirements / use cases
down to software. Of course this is rather a rule of thump, typical
applications contain parts that are rather library-style and other parts
that are rather application-style. So you might end up using both.
I was going to say the same. Two additional remarks: as you mention
implicitely, using bottom-up with tdd might be a bit easier / faster
because you save yourself all those lower level stubs that you need with
top-down and tdd.
i think its much better to use mocks and not stubs for the top-down
approach. also you really benefit from the isolation of the tests when
you use mocks.