Never thought TH-cam should implement a double thumbs-up button, but then I came across this video... Dammit, how I wish I could hit that button a thousand times. This video is pure gold!
This is certainly my default approach to TDD. I've often described it myself and others by talking about testing "behaviours" in contrast to the approach I see quite a bit of trying to test individual methods. I've never been entirely happy with the term "behaviour", and so sometimes I've talked about the tests as "mini use cases", but a lot of people don't really know what a use case is either.
I'm happy to have more suggestions about words to describe TDD. I'm even happier you recognize my approach to TDD as something you also do :-) It seems this video format with theory & demo helps with communication.
@@EmilyBache-tech-coach This approach looks like the sane spot where TDD and BDD meet. No fanatic focus on "the simplest possible implementation", even if it's totally obvious that you will need a "container" like a list and also not tainted by the idea that business SMEs could write good specs if you just give them enough expensive tools.
Hi Emily! I think you make it very clear what usage-first design is, and thank you for making me understand that it is a topic worth explaining in detail, while I might be tempted to give it for granted and assume that devs understand it "automatically". I do wonder; in the exercise, we are basically solving a standard TDD kata, but are we exercising usage-first design? The design of the basket interface is fixed and the session participants will be designing the internals of the class, true, but they will not be given a chance to evaluate alternative designs of the basket interface. I'm just curious; I wonder if you will have another session or exercise that will focus on that.
I'm happy you think usage-first design is a topic worth talking about. Yes, the participants are not being given a chance to actually practice this in this learning hour. The practice is actually in incremental design and understanding what parts still need designing once you've set the external interface. The learning hour after this one (Incremental TDD) is a follow-up where you get to evaluate other alternative designs and a chance to come up with your own.
The first test case is testing no content in the basket, but the function is asking the item name then the test case should be named to no_XXX_item_in_basket
Never thought TH-cam should implement a double thumbs-up button, but then I came across this video... Dammit, how I wish I could hit that button a thousand times. This video is pure gold!
This is certainly my default approach to TDD. I've often described it myself and others by talking about testing "behaviours" in contrast to the approach I see quite a bit of trying to test individual methods. I've never been entirely happy with the term "behaviour", and so sometimes I've talked about the tests as "mini use cases", but a lot of people don't really know what a use case is either.
I'm happy to have more suggestions about words to describe TDD. I'm even happier you recognize my approach to TDD as something you also do :-) It seems this video format with theory & demo helps with communication.
@@EmilyBache-tech-coach This approach looks like the sane spot where TDD and BDD meet. No fanatic focus on "the simplest possible implementation", even if it's totally obvious that you will need a "container" like a list and also not tainted by the idea that business SMEs could write good specs if you just give them enough expensive tools.
Hi Emily! I think you make it very clear what usage-first design is, and thank you for making me understand that it is a topic worth explaining in detail, while I might be tempted to give it for granted and assume that devs understand it "automatically".
I do wonder; in the exercise, we are basically solving a standard TDD kata, but are we exercising usage-first design? The design of the basket interface is fixed and the session participants will be designing the internals of the class, true, but they will not be given a chance to evaluate alternative designs of the basket interface. I'm just curious; I wonder if you will have another session or exercise that will focus on that.
I'm happy you think usage-first design is a topic worth talking about. Yes, the participants are not being given a chance to actually practice this in this learning hour. The practice is actually in incremental design and understanding what parts still need designing once you've set the external interface. The learning hour after this one (Incremental TDD) is a follow-up where you get to evaluate other alternative designs and a chance to come up with your own.
The first test case is testing no content in the basket, but the function is asking the item name then the test case should be named to no_XXX_item_in_basket
Yes you could name it like that. I don't think that's the only way to do test names though.