undefined | Better HN

0 pointspeheje6y ago0 comments

1) Sure but that's the same as saying tests makes navigating the codebase harder because now when you "jump to usages" you find all the references from the tests. Probably fixable by tooling configuration.

2) For each unit test setup an independent mock of the interface for your subject-under-test. You should not create catch-all mocks for all your interfaces, unless it's to be used for offline work.

3) If you replace the process, as in the business process, you need to redo the tests as well yes. If you replace the implementation, you must throw away your "white-box" tests but should be able to keep your "black-box" tests.

0 comments

2 comments · 1 top-level

anonymoushn6y ago· 1 in thread

1) I haven't actually seen a tooling configuration that gives you the experience of having the concrete type in your code when you write code that uses an interface (in e.g. golang or Java) for the sole purpose of swapping it out in a test.

2) Right. I agree.

3) It looks like your original post in this thread says "Do not make black box tests. Make white box tests"

pehejeOP6y ago

1) Me neither to be honest, but would love to see it.

3) All right. That was not my intend. I think they both do different stuff, some projects need both, some only need one or the other.

j / k navigate · click thread line to collapse