Comments on: Design Driven Testing: Using tests as specifications of system’s invariants and contracts design http://sadekdrobi.com/2007/09/29/draft-design-driven-testing-using-tests-as-specifications-of-system%e2%80%99s-invariants-and-contracts-design/ Sadek Drobi Mon, 02 Nov 2009 05:56:20 +0100 http://wordpress.org/?v=2.8.2 hourly 1 By: Fingerprints of Casper Fabricius » Talking at BarCamp Copenhagen http://sadekdrobi.com/2007/09/29/draft-design-driven-testing-using-tests-as-specifications-of-system%e2%80%99s-invariants-and-contracts-design/comment-page-1/#comment-1830 Fingerprints of Casper Fabricius » Talking at BarCamp Copenhagen Wed, 16 Jan 2008 19:29:34 +0000 http://sadekdrobi.com/2007/09/29/draft-design-driven-testing-using-tests-as-specifications-of-system%e2%80%99s-invariants-and-contracts-design/#comment-1830 [...] I could of course be preaching test-driven development (TDD) and show how Rails makes this approach quite easy, but haven’t TDD’ed much in my latest projects, because I was tired of having this huge, always-breaking test suite, which rarely caught any real bugs, and mostly just indicated that my tests was buggy. I’m starting to get a feeling that Cope is right when he says that unit testing can be harmful. [...] [...] I could of course be preaching test-driven development (TDD) and show how Rails makes this approach quite easy, but haven’t TDD’ed much in my latest projects, because I was tired of having this huge, always-breaking test suite, which rarely caught any real bugs, and mostly just indicated that my tests was buggy. I’m starting to get a feeling that Cope is right when he says that unit testing can be harmful. [...]

]]> By: Julien Delhomme’s Blog » Are you really sure Agile is not bad for Design? http://sadekdrobi.com/2007/09/29/draft-design-driven-testing-using-tests-as-specifications-of-system%e2%80%99s-invariants-and-contracts-design/comment-page-1/#comment-778 Julien Delhomme’s Blog » Are you really sure Agile is not bad for Design? Sat, 13 Oct 2007 23:33:21 +0000 http://sadekdrobi.com/2007/09/29/draft-design-driven-testing-using-tests-as-specifications-of-system%e2%80%99s-invariants-and-contracts-design/#comment-778 [...] bugs. The goal of Unit testing must be to define system boundaries and to specify invariants (Design Driven Testing: Using tests as specifications of system’s invariants and contracts desi... – Sadek [...] [...] bugs. The goal of Unit testing must be to define system boundaries and to specify invariants (Design Driven Testing: Using tests as specifications of system’s invariants and contracts desi… – Sadek [...]

]]> By: Sadek Drobi http://sadekdrobi.com/2007/09/29/draft-design-driven-testing-using-tests-as-specifications-of-system%e2%80%99s-invariants-and-contracts-design/comment-page-1/#comment-750 Sadek Drobi Tue, 02 Oct 2007 11:28:06 +0000 http://sadekdrobi.com/2007/09/29/draft-design-driven-testing-using-tests-as-specifications-of-system%e2%80%99s-invariants-and-contracts-design/#comment-750 There are a lot of interesting ideas in our previous discussions, including the "Tools and Materials" metaphor you’ve just mentioned. I really would like to have such discussions public because I guess we tend all to agree on a lot of values and concepts. And we share some understanding of what agile really means. On the other hand, I would prefer to have this kind of discussion in a more neutral place than my personal blog that can be influenced by my ideas. I can suggest publishing a WIKI where we can discuss such ideas, then publish our shared understanding about agile development. I won’t go personally for choosing Wikipedia as I concerned about spam. I can arrange for the host/domain name/installation. I also welcome any other suggestions. For the business invariants, yes I am talking about the integration level, but also talking about tracing them down till the coherent units/elements of the program, be it classes, methods or a whole structure of classes. The aim is to make developers' intention and assumptions more visible. I agree with you that defining business invariants in an up-front manner in the level of integration will have its effects on velocity. That’s why I tried to avoid using the term "test-first" that I, mistakenly, used in the previous post. I tend to agree on the importance of the “test-while” over the rigid “test-first” term. That’s why I mentioned that I do this approach in an iterative way. Still that can be misunderstood as to be a test-first approach. But what I want to say is that at any moment of implementation/test we can go back and modify invariants and assumption in all the levels (from integration level down to the deepest coherent set of elements of the implementation). I guess I should update the post to add that the process I am using is recursive, and that it can go down and up defining/modifying/adding invariants in all the levels of coherent elements of the implementation. There are a lot of interesting ideas in our previous discussions, including the “Tools and Materials” metaphor you’ve just mentioned. I really would like to have such discussions public because I guess we tend all to agree on a lot of values and concepts. And we share some understanding of what agile really means.
On the other hand, I would prefer to have this kind of discussion in a more neutral place than my personal blog that can be influenced by my ideas. I can suggest publishing a WIKI where we can discuss such ideas, then publish our shared understanding about agile development. I won’t go personally for choosing Wikipedia as I concerned about spam. I can arrange for the host/domain name/installation. I also welcome any other suggestions.
For the business invariants, yes I am talking about the integration level, but also talking about tracing them down till the coherent units/elements of the program, be it classes, methods or a whole structure of classes. The aim is to make developers’ intention and assumptions more visible.
I agree with you that defining business invariants in an up-front manner in the level of integration will have its effects on velocity. That’s why I tried to avoid using the term “test-first” that I, mistakenly, used in the previous post. I tend to agree on the importance of the “test-while” over the rigid “test-first” term. That’s why I mentioned that I do this approach in an iterative way. Still that can be misunderstood as to be a test-first approach. But what I want to say is that at any moment of implementation/test we can go back and modify invariants and assumption in all the levels (from integration level down to the deepest coherent set of elements of the implementation). I guess I should update the post to add that the process I am using is recursive, and that it can go down and up defining/modifying/adding invariants in all the levels of coherent elements of the implementation.

]]> By: Cope http://sadekdrobi.com/2007/09/29/draft-design-driven-testing-using-tests-as-specifications-of-system%e2%80%99s-invariants-and-contracts-design/comment-page-1/#comment-748 Cope Tue, 02 Oct 2007 07:01:09 +0000 http://sadekdrobi.com/2007/09/29/draft-design-driven-testing-using-tests-as-specifications-of-system%e2%80%99s-invariants-and-contracts-design/#comment-748 Sadek, I think your description of the architecture/design approach summarizes my JaOO talk beautifully. Add to that the Tools and Materials metaphor that Serge pointed out to us, and the use of Java abstract classes for the domain architecture and of Java interfaces for the tool architecture, and it pretty much sums it up. I like your notion of tieing the tests back to business invariants. Those can usually be found in the Use Cases. However, I can't follow your reasoning of how to bring these invariants to the level of components. I think too many people guess about individual components' invariants at the time they are coding them up. This is reminiscent of what Bas Vodde said at JaOO: that you can use a modified TDD at the integration level. I claim that that's not TDD any more, at least not in the sense of driving the design, and certainly not in the sense that Bob Martin defined TDD. You really are going to write all the integration tests at that level *before* writing any code subject to that scope of integration? A sane person would develop the tests and code in parallel. To do this serialization will greatly decrease your velocity. As Gertrud Bjørnvig points out, It's not "test first" that's important: it's "test-while." Sadek, I think your description of the architecture/design approach summarizes my JaOO talk beautifully. Add to that the Tools and Materials metaphor that Serge pointed out to us, and the use of Java abstract classes for the domain architecture and of Java interfaces for the tool architecture, and it pretty much sums it up.

I like your notion of tieing the tests back to business invariants. Those can usually be found in the Use Cases. However, I can’t follow your reasoning of how to bring these invariants to the level of components. I think too many people guess about individual components’ invariants at the time they are coding them up. This is reminiscent of what Bas Vodde said at JaOO: that you can use a modified TDD at the integration level. I claim that that’s not TDD any more, at least not in the sense of driving the design, and certainly not in the sense that Bob Martin defined TDD. You really are going to write all the integration tests at that level *before* writing any code subject to that scope of integration? A sane person would develop the tests and code in parallel. To do this serialization will greatly decrease your velocity.

As Gertrud Bjørnvig points out, It’s not “test first” that’s important: it’s “test-while.”

]]> By: Sadek Drobi’s Blog » I always write tests before code, but I don’t do Test Driven Development http://sadekdrobi.com/2007/09/29/draft-design-driven-testing-using-tests-as-specifications-of-system%e2%80%99s-invariants-and-contracts-design/comment-page-1/#comment-742 Sadek Drobi’s Blog » I always write tests before code, but I don’t do Test Driven Development Sat, 29 Sep 2007 17:38:06 +0000 http://sadekdrobi.com/2007/09/29/draft-design-driven-testing-using-tests-as-specifications-of-system%e2%80%99s-invariants-and-contracts-design/#comment-742 [...] about this approach to testing in my newer post Design Driven Testing: Using tests as specifications of system’s invariants and contracts desi...… del.icio.us, [...] [...] about this approach to testing in my newer post Design Driven Testing: Using tests as specifications of system’s invariants and contracts desi…… del.icio.us, [...]

]]>