CODEWITHSUNDEEP
unit-testingtestingintegration-testing
Greg Bell
Greg Bell

Reputation: 2219

Does a large suite of unit and integration tests make architectural changes difficult?

If I've been diligent to create unit tests as I go, then integration tests as I put my application together, are my hands a bit tied when I want to refactor the architecture?

It seems like even just pulling a method from one class to another might have quite a bit of overhead getting the tests working again.

Upvotes: 0

Views: 34

Answers (1)

dm03514
dm03514

Reputation: 55972

Maybe

If your unit tests are "change detector", mirroring the implementation of your code, then there will probably be a non-trivial amount of overhead to refactoring.

Additionally, because unit tests just generally deal with implementation details, they will fail as architecture changes. Ideally this failure will be constructive feedback and will inform you to what sorts of contract other parts of your code is expecting.

Writing tests is pretty easy, writing meaningful tests, that don't provide false positives, that are isolated, and don't have cascading failures is way more difficult :) (still trying to figure it out over here).

Testing along your library's public interfaces should help minimize implementation failures. Also, having a large number of solitary unit tests, should help minimize inter component test failures.

One strategy, which I have found very helpful, is when developing MVP's or prototypes, where implementations are being explored, testing at the Acceptance level or functional level help to validate the product, while allowing for lots of leniency in implementation. These tests usually occur along the Services public interface, and not along the codes.

Upvotes: 1

Related Questions