@robby so, in your opinion, I should try to implement a framework for filling my special datastructures with testing-data before testing algorithms that work on them?
What if the framework for filling them is buggy? Do I need tests for my testing code?
@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.
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!