4 ms·

Don't forget a very important thing: unit test are hindering any refactoring. People will resist it because it means they have to rewrite their tests. And if yo

by arkh 5y ago

Don't forget a very important thing: unit test are hindering any refactoring. People will resist it because it means they have to rewrite their tests. And if you don't have enough e2e tests, you have nothing to check your refactoring efforts have not broken anything.

GrumpyNl 5y ago
I have noticed that 80% of the time the unit test fails, the unit test has to be rewritten.
rileymat2 5y ago
Do they hinder refactoring or rewriting? When I am doing legitimate refactoring in simple steps by the book, unit tests are helpful and speed it up. When I am rewriting, I see your issue. For example, a sprout method or sprout class refactor do not change the tests.
hamandcheese 5y ago
If a test is in my way, I delete it.
- amw-zero 5y ago
  Then what is the point of it being there in the first place?
  - booi 5y ago
    The point of what being there? There's nothing there.
    - amw-zero 5y ago
      What is the point of the initial test if you’re just going to delete it.
      - bluGill 5y ago
        Depends on why it failed. Many times it fails because a requirement changed, so delete the no longer valid test
  - hamandcheese 5y ago
    As other said, if/when it comes to this it is because the code in question has change in a significant way. So the point was to test a previous version.
    - BerislavLopac 5y ago
      Tests have nothing to do with the code. They are supposed to test the behaviour.
- Aeolun 5y ago
  Must be fun to work with you.
spaetzleesser 5y ago
Very true. A lot of unit tests, especially the ones with mocks tend to test a lot of internal behavior. So when you refactor your system, you often have to rewrite unit tests although the system actually performs correctly.
rualca 5y ago
> Don't forget a very important thing: unit test are hindering any refactoring. People will resist it because it means they have to rewrite their tests. Well, unit tests verify a contract. If a developer wants to change code but is incapable of respecting a contract (i.e., preserving old invariants or adding new ones that make sense) then he should not be messing with that code at all, shouldn't he? In that sense alone, it's quite clear that unit tests pay off and add a lot of.value, namely in avoiding needless regressions from Rambo developers who want to change code without caring if it even works.
- Normal_gaussian 5y ago
  > unit tests verify a contract This is the most important thing. Rambo can delete all the unit tests he wants in his MR; our discussion will be about whether: - the contracts have changed. - the unit tests shouldn't have been there in the first place. - he's violating contracts
kazinator 5y ago
Test the heck out of the external, documented contracts. Then the test suite helps you refactor: reshuffle the internals while maintaining the contracts.
lowbloodsugar 5y ago
If unit tests are hindering your refactoring then you aren't writing SOLID code. The only time I find myself, e.g. splitting a class in two, and then having to deal with its shitty tests, are when I'm dealing with legacy classes that did five things at once. Oh, and their tests were just "did it crash?" tests, i.e. call a method but only check the happy path. If you have reached the point where you feel tests hinder refactoring then you have two paths: a/ learn to write smaller, SOLID classes, or b/ meh unit tests are stoopid.
Aeolun 5y ago
Lolwut? Unit tests are one of the few things that give me confidence in my refactored code. Integration tests are nice, but they don’t give me enough confidence about the specific part of the system I’m altering.
- bluGill 5y ago
  Until you realize that your api is wrong. So long as you got your api right up front unit tests make it easy to refactor. As soon as the api needs nontrivial changes you are sunk.
  - grayclhn 5y ago
    Cool, but that’s not “refactoring.”
  - Aeolun 5y ago
    True, to some extend. But the number of times I need to do that is low compared to the number of times I need to do a much milder refactor.
  - JoshuaDavid 5y ago
    If your api is wrong, and you have unit tests for that wrong api, and you have time to rewrite it the right way, you can write a set of methods with the correct api which is a shim for the wrong api (you don't care about perf here), write your refactored version, and switch your now-tested shim to the correct api (and then probably keep it as a reference for the new way of doing things). If you find yourself doing this frequently though unit tests might not be ideal for your situation.

by arkh 5y ago

GrumpyNl 5y ago

I have noticed that 80% of the time the unit test fails, the unit test has to be rewritten.

rileymat2 5y ago

Do they hinder refactoring or rewriting? When I am doing legitimate refactoring in simple steps by the book, unit tests are helpful and speed it up. When I am rewriting, I see your issue. For example, a sprout method or sprout class refactor do not change the tests.

hamandcheese 5y ago

If a test is in my way, I delete it.

amw-zero 5y ago
Then what is the point of it being there in the first place?
- booi 5y ago
  The point of what being there? There's nothing there.
  - amw-zero 5y ago
    What is the point of the initial test if you’re just going to delete it.
    - bluGill 5y ago
      Depends on why it failed. Many times it fails because a requirement changed, so delete the no longer valid test
- hamandcheese 5y ago
  As other said, if/when it comes to this it is because the code in question has change in a significant way. So the point was to test a previous version.
  - BerislavLopac 5y ago
    Tests have nothing to do with the code. They are supposed to test the behaviour.
Aeolun 5y ago
Must be fun to work with you.

spaetzleesser 5y ago

Very true. A lot of unit tests, especially the ones with mocks tend to test a lot of internal behavior. So when you refactor your system, you often have to rewrite unit tests although the system actually performs correctly.

rualca 5y ago

> Don't forget a very important thing: unit test are hindering any refactoring. People will resist it because it means they have to rewrite their tests. Well, unit tests verify a contract. If a developer wants to change code but is incapable of respecting a contract (i.e., preserving old invariants or adding new ones that make sense) then he should not be messing with that code at all, shouldn't he? In that sense alone, it's quite clear that unit tests pay off and add a lot of.value, namely in avoiding needless regressions from Rambo developers who want to change code without caring if it even works.

Normal_gaussian 5y ago
> unit tests verify a contract This is the most important thing. Rambo can delete all the unit tests he wants in his MR; our discussion will be about whether: - the contracts have changed. - the unit tests shouldn't have been there in the first place. - he's violating contracts

kazinator 5y ago

Test the heck out of the external, documented contracts. Then the test suite helps you refactor: reshuffle the internals while maintaining the contracts.

lowbloodsugar 5y ago

If unit tests are hindering your refactoring then you aren't writing SOLID code. The only time I find myself, e.g. splitting a class in two, and then having to deal with its shitty tests, are when I'm dealing with legacy classes that did five things at once. Oh, and their tests were just "did it crash?" tests, i.e. call a method but only check the happy path. If you have reached the point where you feel tests hinder refactoring then you have two paths: a/ learn to write smaller, SOLID classes, or b/ meh unit tests are stoopid.

Aeolun 5y ago

Lolwut? Unit tests are one of the few things that give me confidence in my refactored code. Integration tests are nice, but they don’t give me enough confidence about the specific part of the system I’m altering.

bluGill 5y ago
Until you realize that your api is wrong. So long as you got your api right up front unit tests make it easy to refactor. As soon as the api needs nontrivial changes you are sunk.
- grayclhn 5y ago
  Cool, but that’s not “refactoring.”
- Aeolun 5y ago
  True, to some extend. But the number of times I need to do that is low compared to the number of times I need to do a much milder refactor.
- JoshuaDavid 5y ago
  If your api is wrong, and you have unit tests for that wrong api, and you have time to rewrite it the right way, you can write a set of methods with the correct api which is a shim for the wrong api (you don't care about perf here), write your refactored version, and switch your now-tested shim to the correct api (and then probably keep it as a reference for the new way of doing things). If you find yourself doing this frequently though unit tests might not be ideal for your situation.