TDD Process (Test Driven Development)

[valehh]

Hi, I am doing research on what tools can make TDDier's lives easier.
If you are a developer who practices "test driven development" (TDD) please answer the following questions.

Thanks a lot!

Instructions:
Please specify which of the following statements are true when you are modifying existing unfamiliar code or extending it with new functionality in a TDD project:
Please use a number from 1 to 5 where 1 is never and 5 is always.

Example: I read tests to understand the program : 2

Questions:
1- I read tests to understand the program:
2- I run tests and trace them to understand the program:
3- I change the program code and then change and augment all the broken tests:
4- Before I make any changes to the code, I first discover and make changes to tests that are relevant to the functionality of interest and then make the changes to the code to pass them:
5- I do not try to find the relevant tests. Instead, I write a set of new tests from scratch and then make changes to the code to pass them. Then I fix any other broken tests later:
Other:

Copy Right: Valeh H. Nasser, 2010

[Dadidum]

(A) When you want to add functionality to unfamiliar code, how often do you read the tests to understand the program?

1. Seldom
2. Sometimes
3. Usually


I don't understand, in interviews, people only hand me a test paper with source code printed, I have to read line by line with my eyes and write out what the output is, where is the test
Also, to unfamiliar code, test this out myself that I have a habit to try running it in IDE with compiler to see the results. I call it a test too

(B) When you are changing existing functionality, what process do you follow? please order the following tasks. Do not use a task if you do not do it. You can use a task multiple time. Please describe what you actually do and not what you think should be done.

1. Refactor te code,
2. Change the code,
3. I disregard whether any tests relevant to the functionality of interest exists,
4. I discover, read, and examine the existing tests relevant to the functionality of interest,
5. If I do not know the program, I will read tests to understand how the program works,
6. If I do not know the program, I will run tests and trace them to understand how the program works,
7. If I do not know the program, I will run the program (not the test) to understand how it works,
8. If I do not know the program, I will read the program (not the test) to understand how it works,
9. I write new tests for what I am changing (some tests might be contradicting existing tests),
10. I Write new tests for new classes,
11. I change existing tests,
12. I fix failed tests,
13. I watch tests fail,

Before changing the program, I tend to look into how the program works, especially what the outcome likely is for given inputs, I believe people when handed in a program will first check to see if it is a virus then run it, definitely no run in "tests", [that's a lengthy and classical but correct path]. Refactoring the code still seems way too far; and options from 9 to 13 probably solely suit for theoretical professionals

(Edit: By the way, thanks a lot for your survey, it also helps broaden my mind too over tests - I love tests but tests don't seem too much necessary in the development cycle - )

[Turingmachine]

For A, I choose 2. Because I always receive cool sources from colleague, well written in readable forms (comments/notes including output samples from the code snips etc)
For B I pick10, I write new tests for new classes, and change and fix the existing test if I can

Very nice, good research project you are working on.

[valehh]

Thanks for your reply. I modified the question to be easier to reply.

[valehh]

Here is the new question:
Please specify which of the following statements hold when you are modifying existing unfamiliar code or extending it with new functionality:
Please use seldom/sometime/usually or true/false values:
Example: I read tests to understand the program : sometimes

Questions:
1- I read tests to understand the program:
2- I run tests and trace them to understand the program:
3- Before I make any changes to the code, I first discover tests that are relevant to the functionality of interest and then make the changes:
4- I do not try to find the relevant tests. Instead, I write a set of new tests from scratch and then make changes to the code to pass them. I fix any other failing tests later:
5- I change the program code and then change and augment all the broken tests:

Other:

Copy Right: Valeh H. Nasser, 2010

[Maejie]

Excelent !

1- I read tests to understand the program: sometimes
2- I run tests and trace them to understand the program: sometimes
3- Before I make any changes to the code, I first discover tests that are relevant to the functionality of interest and then make the changes: sometimes
4- I do not try to find the relevant tests. Instead, I write a set of new tests from scratch and then make changes to the code to pass them. I fix any other failing tests later: nope because I can't
5- I change the program code and then change and augment all the broken tests: always, because I want it to be mine instead

[valehh]

Thanks for your reply Maejie.