TDD Process (Test Driven Development)

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

(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 - :D)

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. :)

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

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

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

Thanks for your reply Maejie. :)