@robby @janriemer @musicmatze Step 5 would be refactor your code so that it meets coding guidelines for your organization or project, and step 6 would be to re-test to make sure you didn't break anything in the mean time. Step 7 would be fin. For projects that need it, step 7 would also be to write documentation covering what you've just coded; but, that's a subjective judgement call.
That said, all 7 steps occur several times per hour (yes, per hour), not per week or sprint. If your customer is changing requirements at a rate of several times per day, in a way that impacts what you're doing, it's time to sit down with the customer and re-evaluate their terms of their development contract.
The granularity for your tests are minute; individual features of individual functions on a single user-story. Hence why they're called unit tests.
The whole idea is literally to introduce at most one bug at a time, so you know exactly where and how to fix it. (Missing features are treated as bugs in this case.) OK, sometimes you introduce more than one bug during a session; it happens. But, it's quite rare to introduce so many that it's unmanageable. And, your proficiency with the idea improves with practice, like anything else.
@robby @janriemer @musicmatze Oh, and if you need to research how to make something in the first place, you are free to use whatever approach you're comfortable with to hack up a prototype. This is called a "spike", and many projects have several spikes associated with them.
The purpose of the spike is to get a handle on the scope of a solution to a problem. They're not intended to become production-ready code. Just quick hacks. Thus, these don't (and, many would argue, should not) need TDD to develop.
Spikes are throw-away code. Once you have the experience of a solution that a spike provides, you can use that to guide your TDD work to produce a "production-ready" (such as it may be) version of the code. It sounds like you're duplicating work, and to some extent you are. However, the pay-off is not having to do a ground-up rewrite later on, something I've ended up having to do on many commercial projects in the past because the original authors decided to jump to another job rather than rework their earlier code for better maintainability.
@musicmatze Oh, that's really cool you had TDD at Uni.
We didn't (not even unit testing).😢
kairos crate looks really interesting. Thank you.🙂
1. Tests must be understood easily - if you are hiding away the inputs and the "acting" of the SUT (system under test) behind some abstraction to reduce duplication, you make it maybe easier to maintain, but much harder to understand what the test should verify.
2. If you have a lot of "acting" to do on your SUT and, as a consequence, a lot of duplication of method call sequences between your tests, this is actually an indication that you should build an abstraction for it _in your production code_.
This Mastodon instance is for people interested in technology. Discussions aren't limited to technology, because tech folks shouldn't be limited to technology either!