3 ms·

Refactoring code usually means you have to refractor unit tests as well, since they are so closely tied to the structure of the code. Integration tests, howeve

Refactoring code usually means you have to refractor unit tests as well, since they are so closely tied to the structure of the code. Integration tests, however, should not have to change, since they are typically run against the external interface to the software, which shouldn't change if you're just doing a refactoring.

juandazapata 9y ago
Funny thing. Unit tests force you to think about good code design. Integration tests don't. If you only have integration tests in your system, you'll most likely end up with a big ball of mud. I've seen this so many times in so many real world projects that it hurts.
- mannykannot 9y ago
  > Funny thing. Unit tests force you to think about good code design. Integration tests don't. They absolutely do, but at higher levels of abstraction, in terms of interfaces, interactions, constraints, obligations and responsibilities. In fact, unit and integration tests make you think about design in essentially the same way.
  - juandazapata 9y ago
    Whatever floats your boat. My experience in large enterprise products is exactly the opposite, but I'm glad it works for you.
- wtetzner 9y ago
  Except that in my experience, unit tests just end up being a big ball of mud too. And at that point, they don't make refactoring easier, they actually make it harder. Having good integration tests means that you're free to completely re-organize your code, and you can still test that it works as expected. Given that requirements change over time, even a well thought out code structure will likely need to be refactored at some point, and being able to have a test suite that doesn't have to be re-written during a refactoring is extremely valuable. I've also seen code bases become unnecessarily complex because so much thought was put into how to unit test it, that not enough thought was put into writing clear, easy to understand code.
wmil 9y ago
Yes, but broken tests at least give you hints about where you need to fix things. It can be hard to find every piece of code that relies on something you're changing.

juandazapata 9y ago

Funny thing. Unit tests force you to think about good code design. Integration tests don't. If you only have integration tests in your system, you'll most likely end up with a big ball of mud. I've seen this so many times in so many real world projects that it hurts.

mannykannot 9y ago
> Funny thing. Unit tests force you to think about good code design. Integration tests don't. They absolutely do, but at higher levels of abstraction, in terms of interfaces, interactions, constraints, obligations and responsibilities. In fact, unit and integration tests make you think about design in essentially the same way.
- juandazapata 9y ago
  Whatever floats your boat. My experience in large enterprise products is exactly the opposite, but I'm glad it works for you.
wtetzner 9y ago
Except that in my experience, unit tests just end up being a big ball of mud too. And at that point, they don't make refactoring easier, they actually make it harder. Having good integration tests means that you're free to completely re-organize your code, and you can still test that it works as expected. Given that requirements change over time, even a well thought out code structure will likely need to be refactored at some point, and being able to have a test suite that doesn't have to be re-written during a refactoring is extremely valuable. I've also seen code bases become unnecessarily complex because so much thought was put into how to unit test it, that not enough thought was put into writing clear, easy to understand code.

wmil 9y ago

Yes, but broken tests at least give you hints about where you need to fix things. It can be hard to find every piece of code that relies on something you're changing.