@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.
@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.🙂
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!