51–60 of 329 posts
No, in fact, we don’t use coded tests at all, deliverables are tested by the product owner(s). On the code level, we hardly see bugs, not even when refactoring. I often wonder if it is luck or expertise, and whether we would benefit from writing tests.
Also I try to test at subsystem / API boundaries whenever possible. Small units like a function rarely get their own tests, they are covered implicitly by being used. This avoids tests of arbitary internals (that should be free to change) becoming a maintenance burden. External APIs should be stable.
- when it’s really easy
- when it’s really important
- before a refactor
But most of the time, fixing some bug or implementing a feature is more of experimenting and prototyping at first. Writing tests for every futile attempt would be a waste of time.
At best we design some small architecture first with interfaces, and then create the tests off that.
I follow the Functional Core, Imperative Shell pattern. I do TDD on Core, especially on mission critical code. The Shell however have almost zero automated tests.
I mean how many of you stick with this test driven development practice consistently? I have been doing this for a while now. Practically, saves me a tonne of time and am able to ship software confidently. Can you describe the practical benefit? Say, a change is executed on one section of the (enterprise level)application. You missed addressing an associated section. This is easily identified as your test will FAIL.…
The benefits you describe seems to be achievable with tests written after code as well. We write extensive unit tests, but mostly after development work. The re-write work you mention is then avoided.
> Can you describe the practical benefit?
Confidence that the code I'm writing does what it's supposed to. With the added benefit that I can easily add more tests if I'm not confident about some behaviors of the feature or easily add a test when a bug shows up.
> Do you happen to rewrite the tests completely while doing the implementation?
Not completely, depends on how you write your tests, I'm not testing each function individually, I'm testing behaviour, so unless there's a big architectural change or we need to change something drastic, the tests have minimal changes
> When does this approach work for you and when did it fail you?
It works better on layered architectures, when you can easily just test the business logic independently of the framework/glue code. It has failed me for exploratory work, that's the one scenario where I just prefer to write code and manually test it, since I don't know what I want it to do...yet
If you write your test after making the code changes, its easier to have a bug in your test that makes it pass for the wrong reasons. By writing the test first, and progressively, you can be sure that each thing it asserts fails properly if the new code you write doesn't do what is expected.
Sometimes I do write the code first, and then I just stash it and run the new tests to be sure the test fails correctly. Writing the test first is simply a quicker way to accomplish this.
Like others have said when there is a lot of new code - new architectural concerns etc, its not really worth it to write tests until you've sketched things out well-enough to know you aren't so likely to have major API changes. Still, there is another benefit to writing the tests - or at least defining the specs early on - which is that you are not as likely to forget testing a particular invariant. If you've at least got a test file open and can write a description of what the test will be, that can save you from missing an invariant.
Think of tests as insurance that someone working on the code later (including yourself, in the future) doesn't break an invariant because they do not know what they all are. Your tests both state that the invariant is intentional and necessary, and ensure it is not broken.
Testing simple code is simple and therefore pretty much useless. Testing complicated code is complicated and therefore more likely to fail by making to few or to many assumptions in the test, or completely screwing up the test code itself.