Comments on: The Tests are the Requirements http://elegantcode.com/2008/02/05/the-tests-are-the-requirements/ Wed, 28 Jul 2010 21:28:29 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: Elegant Code » Everything I ever wanted to know about Agile Development I learned… http://elegantcode.com/2008/02/05/the-tests-are-the-requirements/comment-page-1/#comment-18206 Elegant Code » Everything I ever wanted to know about Agile Development I learned… Sat, 15 Mar 2008 07:22:05 +0000 http://elegantcode.com/2008/02/05/the-tests-are-the-requirements/#comment-18206 [...] Verification.  In the simplest form this is a way to have the tests match the requirements (as David put it).  In a broader form it is to verify program program correction overall.  To many [...] [...] Verification.  In the simplest form this is a way to have the tests match the requirements (as David put it).  In a broader form it is to verify program program correction overall.  To many [...]

]]> By: David Starr http://elegantcode.com/2008/02/05/the-tests-are-the-requirements/comment-page-1/#comment-17621 David Starr Thu, 07 Feb 2008 06:30:02 +0000 http://elegantcode.com/2008/02/05/the-tests-are-the-requirements/#comment-17621 We have 2 options to ensure realization of requirements in code. 1. Hand test the requirements by creating a test plan from them. 2. Automate the requirements as tests themselves by expressing requirements as tests in the first place. I think we are focusing on simply skipping the part where we translate requiremetns into a test plan, and then into (maybe) manual tests for regression, and then automating the tests if possible. This simply means "let's express the requirements in an automatable way in the first place, and skip the human translation." We have 2 options to ensure realization of requirements in code.

1. Hand test the requirements by creating a test plan from them.
2. Automate the requirements as tests themselves by expressing requirements as tests in the first place.

I think we are focusing on simply skipping the part where we translate requiremetns into a test plan, and then into (maybe) manual tests for regression, and then automating the tests if possible.

This simply means “let’s express the requirements in an automatable way in the first place, and skip the human translation.”

]]> By: dcarver http://elegantcode.com/2008/02/05/the-tests-are-the-requirements/comment-page-1/#comment-17611 dcarver Thu, 07 Feb 2008 02:24:53 +0000 http://elegantcode.com/2008/02/05/the-tests-are-the-requirements/#comment-17611 Interesting. Where does a traceability matrix fit in? How do you ensure all of your requirements are realized in code (or some other form)?. Also your fitnesse link seems to be pointed to the wrong place. I think you want http://www.fitnesse.org although that site seems very slow. Interesting. Where does a traceability matrix fit in? How do you ensure all of your requirements are realized in code (or some other form)?. Also your fitnesse link seems to be pointed to the wrong place. I think you want http://www.fitnesse.org although that site seems very slow.

]]> By: Chris Brandsma http://elegantcode.com/2008/02/05/the-tests-are-the-requirements/comment-page-1/#comment-17590 Chris Brandsma Wed, 06 Feb 2008 04:10:32 +0000 http://elegantcode.com/2008/02/05/the-tests-are-the-requirements/#comment-17590 Something I have said when teaching TDD, and Jeremy Miller recently reiterated as well: TDD helps your code architecture. If you write your code with an eye towards testability you will naturally head down numerous best practices; like Separations of Concerns, Single Responsibility, Inversion of Control, etc. So, not only do you get better code because it is tested, but you get better code because you are forced to write better code in order for the code to be tested. (that might be confusing to read -- oh well, it is late). Viva la TDD. Something I have said when teaching TDD, and Jeremy Miller recently reiterated as well: TDD helps your code architecture.

If you write your code with an eye towards testability you will naturally head down numerous best practices; like Separations of Concerns, Single Responsibility, Inversion of Control, etc.

So, not only do you get better code because it is tested, but you get better code because you are forced to write better code in order for the code to be tested. (that might be confusing to read — oh well, it is late).

Viva la TDD.

]]>