You thinking in DDD because in CDD there is no domain logic. Everything is part of stack trace tree
You thinking in DDD because in CDD there is no domain logic. Everything is part of stack trace tree
For some “can't” statements, you don't need to write any error.
The “can't” statements in CDD are for actions and input that you could take, but the software deliberately prevents you from doing them.
There are no actions or input, requested from the exercise that make it possible to do the list you gave me, so it does not make sense to create an error for them.
People who think that specifically TDD is a programming technique didn't get the entire memo. It can drive you to design and re-design your app's inputs. But that part of TDD is tacit - hard to teach.
where in the article say that CDD does not care about inputs?
Also in the article says "The main idea of TDD is to design the software through tests." do you disagree with that?
Not being able to quickly think of more test cases for whatever you're trying to test at any given moment does not prove anything. You also seem to be very hung up on something about stack traces that I'm really not able to figure out what it really is, even though you keep mentioning it.