4 ms·

It's perhaps not rigorously scientific, but our red mine server is tied into our Jenkins continuous integration server, which also has a code coverage tool tied

by swalsh 14y ago

It's perhaps not rigorously scientific, but our red mine server is tied into our Jenkins continuous integration server, which also has a code coverage tool tied in. We've been doing this for a little while, and have the ability to visualize bug counts divided by severity along side test count, and code coverage percentage. There is an order of magnitude difference from the projects that did not use TDD, and the projects that did. Another nice part of red mine is that I can also visualize how close we are at meeting our expectations for time estimates (they have this task tracking feature). Overall adding TDD has made development a bit slower in the front end, but a lot shorter in the back end (during QA). However when you look at the past, it would seem like something like 60% to 70% of our time was actually spent fixing issues found in QA, which was usually under estimated. So overall we're definitely seeing quantitative proof that TDD is a better methodology in comparison to our past process. Anther cool tool for project management is we've built a set of tools that allow us to designate a requirement from our functional spec with a unit test, which runs every check in. So our project manager can get a near real time assessment of our progress. I also use that report and associate it with the code coverage report. Though this part of the system is newer, so I have no data on how effective it is.

jbrechtel 14y ago
It'd be great if you would write a blog post with more details about the TDD vs non-TDD projects. Things like: Duration of observation team size (over time) survey of team members anyone go from one team to another? Someone with perspective across both teams would be good. Domain complexity of each project Other code metrics (cyclomatic complexity, coupling, etc) A post would be nice as a reference (as opposed to a comment here). Not a small request, I understand, but I'm sure others would find it very valuable too.
coopdog 14y ago
Do you find linking unit tests to functional requirements useful? I've also been toying with visual traceability (requirementweaver.com) and it seems to have a lot of potential to speed up the traditionally slow 'quality process'
- swalsh 14y ago
  Like I said, its a really new thing for us so I don't have a lot of experience yet. The most immediate benefit i saw though was that we spent more time on the functional spec than we typically do making sure it was complete. That process yields a lot of benefits (its far easier to delete paragraphs, then code). Beyond that though, its nice to see a bit more details on your progress as the development continues. We definitely have more productive status meetings. We used to sit down once a week, and go around the table asking people where they are, but now everyone knows the status all the time (we all can see it). That allows us to spend more time on discussing problem solutions. During development, developers keep track of their own progress with less work. As a lead, its useful for me to see areas of weakness so I can have more targeted code reviews.

by swalsh 14y ago

jbrechtel 14y ago

It'd be great if you would write a blog post with more details about the TDD vs non-TDD projects. Things like: Duration of observation team size (over time) survey of team members anyone go from one team to another? Someone with perspective across both teams would be good. Domain complexity of each project Other code metrics (cyclomatic complexity, coupling, etc) A post would be nice as a reference (as opposed to a comment here). Not a small request, I understand, but I'm sure others would find it very valuable too.

coopdog 14y ago

Do you find linking unit tests to functional requirements useful? I've also been toying with visual traceability (requirementweaver.com) and it seems to have a lot of potential to speed up the traditionally slow 'quality process'

swalsh 14y ago
Like I said, its a really new thing for us so I don't have a lot of experience yet. The most immediate benefit i saw though was that we spent more time on the functional spec than we typically do making sure it was complete. That process yields a lot of benefits (its far easier to delete paragraphs, then code). Beyond that though, its nice to see a bit more details on your progress as the development continues. We definitely have more productive status meetings. We used to sit down once a week, and go around the table asking people where they are, but now everyone knows the status all the time (we all can see it). That allows us to spend more time on discussing problem solutions. During development, developers keep track of their own progress with less work. As a lead, its useful for me to see areas of weakness so I can have more targeted code reviews.