3 replaced http://programmers.stackexchange.com/ with https://softwareengineering.stackexchange.com/
source | link

@CarlManaster@CarlManaster has the right idea: It's the responsibility of the developer to:

  1. write a unit test,
  2. verify that it fails,
  3. implement it,
  4. verify that it succeeds,
  5. refactor the feature without failing the test, and finally
  6. refactor the test code

for every feature. The reason for each of these can be summarised as follows:

  1. Writing the test before the code ensures that the problem is sufficiently understood to actually do the right thing. You can still do exploratory programming, but TDD means you then have to throw away the result and start again by writing tests.
  2. If your test doesn't fail before implementing the feature, you typically are either testing the wrong thing or you don't understand the problem well enough.
  3. Implementing the actual feature is kind of the point :)
  4. Verifying that the test now succeeds makes sure that you have a short cycle to fix it.
  5. Refactoring is crucial to make sure the complexity of your application doesn't get out of hand. If you have tests for every feature refactoring them shouldn't break anything.
  6. Test code should be refactored for the same reason as above. This can be tricky since you need to make sure the tests still test the same things as before. One way to avoid breaking them is, for each test that you touch (directly or indirectly), to break it by changing for example a single character in the expected output, and running it to see that it fails for the right reason. Then just undo the change, and the test should still pass and still do the right thing.

@CarlManaster has the right idea: It's the responsibility of the developer to:

  1. write a unit test,
  2. verify that it fails,
  3. implement it,
  4. verify that it succeeds,
  5. refactor the feature without failing the test, and finally
  6. refactor the test code

for every feature. The reason for each of these can be summarised as follows:

  1. Writing the test before the code ensures that the problem is sufficiently understood to actually do the right thing. You can still do exploratory programming, but TDD means you then have to throw away the result and start again by writing tests.
  2. If your test doesn't fail before implementing the feature, you typically are either testing the wrong thing or you don't understand the problem well enough.
  3. Implementing the actual feature is kind of the point :)
  4. Verifying that the test now succeeds makes sure that you have a short cycle to fix it.
  5. Refactoring is crucial to make sure the complexity of your application doesn't get out of hand. If you have tests for every feature refactoring them shouldn't break anything.
  6. Test code should be refactored for the same reason as above. This can be tricky since you need to make sure the tests still test the same things as before. One way to avoid breaking them is, for each test that you touch (directly or indirectly), to break it by changing for example a single character in the expected output, and running it to see that it fails for the right reason. Then just undo the change, and the test should still pass and still do the right thing.

@CarlManaster has the right idea: It's the responsibility of the developer to:

  1. write a unit test,
  2. verify that it fails,
  3. implement it,
  4. verify that it succeeds,
  5. refactor the feature without failing the test, and finally
  6. refactor the test code

for every feature. The reason for each of these can be summarised as follows:

  1. Writing the test before the code ensures that the problem is sufficiently understood to actually do the right thing. You can still do exploratory programming, but TDD means you then have to throw away the result and start again by writing tests.
  2. If your test doesn't fail before implementing the feature, you typically are either testing the wrong thing or you don't understand the problem well enough.
  3. Implementing the actual feature is kind of the point :)
  4. Verifying that the test now succeeds makes sure that you have a short cycle to fix it.
  5. Refactoring is crucial to make sure the complexity of your application doesn't get out of hand. If you have tests for every feature refactoring them shouldn't break anything.
  6. Test code should be refactored for the same reason as above. This can be tricky since you need to make sure the tests still test the same things as before. One way to avoid breaking them is, for each test that you touch (directly or indirectly), to break it by changing for example a single character in the expected output, and running it to see that it fails for the right reason. Then just undo the change, and the test should still pass and still do the right thing.
2 added 1277 characters in body
source | link

@CarlManaster has the right idea: It's the responsibility of the developer to:

  1. write a unit test,
  2. verify that it fails,
  3. implement it,
  4. verify that it succeeds, and finally
  5. refactor the result to make it as simple as possiblefeature without failing the test, and finally
  6. refactor the test code

for every feature. The reason for each of these can be summarised as follows:

  1. Writing the test before the code ensures that the problem is sufficiently understood to actually do the right thing. You can still do exploratory programming, but TDD means you then have to throw away the result and start again by writing tests.
  2. If your test doesn't fail before implementing the feature, you typically are either testing the wrong thing or you don't understand the problem well enough.
  3. Implementing the actual feature is kind of the point :)
  4. Verifying that the test now succeeds makes sure that you have a short cycle to fix it.
  5. Refactoring is crucial to make sure the complexity of your application doesn't get out of hand. If you have tests for every feature refactoring them shouldn't break anything.
  6. Test code should be refactored for the same reason as above. This can be tricky since you need to make sure the tests still test the same things as before. One way to avoid breaking them is, for each test that you touch (directly or indirectly), to break it by changing for example a single character in the expected output, and running it to see that it fails for the right reason. Then just undo the change, and the test should still pass and still do the right thing.

@CarlManaster has the right idea: It's the responsibility of the developer to:

  1. write a unit test,
  2. verify that it fails,
  3. implement it,
  4. verify that it succeeds, and finally
  5. refactor the result to make it as simple as possible without failing the test

for every feature.

@CarlManaster has the right idea: It's the responsibility of the developer to:

  1. write a unit test,
  2. verify that it fails,
  3. implement it,
  4. verify that it succeeds,
  5. refactor the feature without failing the test, and finally
  6. refactor the test code

for every feature. The reason for each of these can be summarised as follows:

  1. Writing the test before the code ensures that the problem is sufficiently understood to actually do the right thing. You can still do exploratory programming, but TDD means you then have to throw away the result and start again by writing tests.
  2. If your test doesn't fail before implementing the feature, you typically are either testing the wrong thing or you don't understand the problem well enough.
  3. Implementing the actual feature is kind of the point :)
  4. Verifying that the test now succeeds makes sure that you have a short cycle to fix it.
  5. Refactoring is crucial to make sure the complexity of your application doesn't get out of hand. If you have tests for every feature refactoring them shouldn't break anything.
  6. Test code should be refactored for the same reason as above. This can be tricky since you need to make sure the tests still test the same things as before. One way to avoid breaking them is, for each test that you touch (directly or indirectly), to break it by changing for example a single character in the expected output, and running it to see that it fails for the right reason. Then just undo the change, and the test should still pass and still do the right thing.
1
source | link

@CarlManaster has the right idea: It's the responsibility of the developer to:

  1. write a unit test,
  2. verify that it fails,
  3. implement it,
  4. verify that it succeeds, and finally
  5. refactor the result to make it as simple as possible without failing the test

for every feature.