No. Producing the *right* software has nothing to do with an unlimited budget.

Engineering development practices are only one piece of a puzzle in profitability. A solution can be TDD’d to death, but if no one uses it, it’s not a success.

But I’ve seen plenty of projects fail because they collapse under their own weight, unable to change any more because no one knows 1) if the changes they make are right and 2) if they don’t break anything with the change. This software is still “successful” in terms of revenue, but is very expensive to change.

Our clients know what they want, after conversations and the 5 whys, which is what BDD is meant to drive out. Stories + acceptance criteria give us the starting point.

On the other hand, I’m curious how one team responsible for 20 projects has any success at all. Humans are terrible at context switching. Depends on your definition of “project” I guess.

I’ve never understood how one team responsible for 20 projects (that vary in size) can implement BDD or TDD and actually turn a profit. According to the Agile *experts* in my group – the client doesn’t know what they want, so how do I define my tests?

7. Behavior is about the interactions between components of the system and so the use of mocking is a fundamental to advanced TDD.

I’m not sure what you meant by this. Do you mean mock the domain classes when testing higher layers, mocking one domain class when testing another or alternatively mocking other layers when testing the domain? None of these are shown in the examples, in fact they all seem to be using real domain objects.

Anyway I find the workflow you are discussing interesting, the collaboration between the business person (or someone bridging the technology and domain teams) and the developer seems sensible (though difficult to achieve).

“The software will be easy to use”

I would say those are unimplementable contraints because the latter means nothing (“easy to use”…according to whom, when, where), and the former means nothing without knowing deep level implementation details that cannot be bridged simply by having a ubiquitous language.

They aren’t testable at all that I can see.

I believe Mike Cohn refers to your situation as Guiding Principle Cards

http://www.amazon.com/User-Stories-Applied-Development-Addison-Wesley/dp/0321205685/ref=pd_bxgy_b_img_b/002-2360359-6552835

Guiding Principals are the practice of annotating a story card with “GP” for any story that must be obeyed rather than directly implemented. An example can be seen in the following examples

Other examples of constraints are:

• Do not make it hard to internationalize the software if needed later.
• The new system must use our existing order database.
• The software must run on all versions of Windows.
• The system will achieve uptime of 99.999%.
• The software will be easy to use.

Even though guiding principal cards do not get estimated and scheduled into iterations like normal cards they are still useful. Acceptance tests can be written to ensure the guiding principal is not violated. Ideally the team would write this test during one of the first iterations (Spike) when there’s little chance of it being violated. The team would then continue running the test as part of each subsequent iteration.

I know this may not help your particular situation but it may set the stage for a talking point between the DBA and the business analyst early in the project.

1. Our goal is to synergize the acceptance testing framework into the actual codebase. Within the code you should be able to now trace backwards through a reference tree to determine the origination point of why the class was created within the domain layer. By imbedding the story authoring framework from within the unit test framework everyone in the team is focused on the same constructs. I am not recommending replacing any existing unit testing framework, I am suggesting that we extend the unit test framework to be more encompassing of the intention of software as governed by the Story authorship. Similar to how a mocking framework does not replace unit testing it just make it more expressive on the intention of behavior as the consuming class acts upon the mock object.

It’s important to note that these are not new concepts. Rbehave is already doing this in the Ruby world. Rbehave coupled with rspec is quiet powerful.

2. I am never said it was going to be easy. I did work with the BA after I wired the delegates, she simply extended the scenarios to adhere to new aspects of the assertion criteria such as boundary and negative testing. She was curious about what the code did but it didn’t stop her from copy and pasting the other scenarios. What she did find as a benefit was she accidently deleted one of the scenarios and went back in to the source code repository to roll back to the previous version. She also liked how she could compare what she was about to check in with what she had done previously. I will mention that I have tried this on two business analyst. With the first one it immediately clicked. The second however struggled the entire time. I had to spend up to 3 times longer than the first individual mentoring her on how to use behave#. Some people would say give up, I say bring it on! I am going to hold a training session at the end of the next quarter to the department as a whole to gauge the general acceptance.

1. There’s a reason to keep business tests and technical tests separate, so why do you think we can mix them together all of a sudden?

2. JSP tried to make programming look like HTML, and it failed miserably at meeting the objective of making non-programming web designers feel comfortable working with JSP. What makes you think that a business person will feel comfortable editing a Behave# test once a programmer has put in his delegates?