Can't Driven Development
rm4n0s.github.io
Can't Driven Development
1–10 of 54 posts
Re: Can't Driven Development
#2The best way to architect, test and develop software
Re: Can't Driven Development
#3This is just TDD. Your tests should be written to verify and gaurd against "cants" not verify the happy path
Re: Can't Driven Development
#4The best way to architect, test and develop software
Can you describe how this is different from TDD.
From what I understood it seemed like you listed a collection of requirements for TDD failure cases, named them "can't" statements and then did TDD on them. But I believe there is more to it, but I couldn't see it.
Could you list the types test cases you would have created if you had done TDD on this same problem? And how they'd be different?
Re: Can't Driven Development
#5Guard conditions, assertions, constraints and tests are dynamic limits on code and are critical to maintain quality despite code rot and drift from changes.
Static constraints like types can also be also good, where types are good.
I applaud anyone who advocates to focus on the unhappy path over the happy path.
On a side note 25 years ago was the end of the dot.com and the height of the y2k scam and I have never seen developers more burnt out than then; but that’s because I was just starting my career then. I don’t know about previous eras like the 89 crash and recession.
I am not sure why the OP has rose coloured glasses of the past. But it’s always good to treat history with a little more interest.
Re: Can't Driven Development
#6The best way to architect, test and develop software
Can you describe how this is different from TDD. From what I understood it seemed like you listed a collection of requirements for TDD failure cases, named them "can't" statements and then did TDD on them. But I believe there is more to it, but I couldn't see it. Could you list the types test cases you would have created if you had done TDD on this same problem? And how they'd be different?
In TDD, I would have to iterate over the hello_from procedure 900 times to create the software design.
In CDD, I created first the software design by translating "can't" statements to errors and then iterate over the errors following specific rules to create a tree of stack traces that created the software design and then I TDD over that design to complete the application.
Re: Can't Driven Development
#7This is just TDD. Your tests should be written to verify and gaurd against "cants" not verify the happy path
It is not TDD because CDD does not architect the software through refactoring passed tests.
It architects the code from the errors by following specific rules
Re: Can't Driven Development
#8Guard conditions, assertions, constraints and tests are dynamic limits on code and are critical to maintain quality despite code rot and drift from changes. Static constraints like types can also be also good, where types are good. I applaud anyone who advocates to focus on the unhappy path over the happy path. On a side note 25 years ago was the end of the dot.com and the height of the y2k scam and I have never seen…
I put coloured glasses on the past because back then companies didn't request developers to know more than one programming language. They just used fancy words for simple tasks.
Re: Can't Driven Development
#9This doesnt make a lot of sense. The set of things your software cant do is infinite. The set of potential errors is massive and many if not most are unrelated to domain logic.
Re: Can't Driven Development
#10This doesnt make a lot of sense. The set of things your software cant do is infinite. The set of potential errors is massive and many if not most are unrelated to domain logic.
I think it's is finite. I couldn't think of another "can't" statement for my exercise. If you find any please tell me to patch the code.
You thinking in DDD because in CDD there is no domain logic. Everything is part of stack trace tree