@21:28 Allen recommends "TDD by Example" by Kent Beck to learn about TDD. Part I is the core of the book and it uses Java. Part II uses Python. Part III is patterns which I skimmed. I didn't get much out of it the first time, so I watched lectures by Kent, Uncle Bob (Clean Code) and Ian Cooper (TDD). Then I went back and read it again and found it to be excellent. For more TDD examples with code, there are many TH-cams in Java, Python or C#.
If you still do big upfront design with UML and need to develop a system driven entirely by User input, and want to transition to Tests Driven Development, DbC could be a good intermediate step. However, it directly models real world Roles with Classes which I think is problematic, and also assumes that the Users will want to write behavioral tests, whereas they actually never have time to red them. I think this is well worth watching - it certainly gave me a lot to think about - but before attempting it, I would review Allen's more recent output to see if he even still advocates DbC and if so, what changes he's made to it. Personally, I don't see a need for this front end to TDD.
I guess I remain the weird one. I don't want to read your code, no matter how wonderful and beautiful it is, to understand how it works. Give me your API docs. If I have more questions, then perhaps I will read it. I should not have to read your damn code to use it.
The interface is the API docs. You have the type signatures and you can add javadoc style comments on every definition. There you have the API docs. You don't need to read the actual implementation. Nobody wants to read implementations in order to understand how to use an API. This is what Allen is trying to point out.
You misunderstand entirely. He's talking about the interfaces, which are in fact code. You can generate an API doc from the interfaces if you want to read it that way, but it is still design by coding. You can even write out the interfaces and then write the acceptance tests first before writing implementation: both writing interfaces and writing acceptance tests is "writing code". That's the "design by code" Holub is referring to here. Read the sub-title of the talk: extending TDD and BDD into a design process. He's saying design by writing acceptance tests, interfaces, and behaviorally-driven unit tests first.
@21:28 Allen recommends "TDD by Example" by Kent Beck to learn about TDD. Part I is the core of the book and it uses Java. Part II uses Python. Part III is patterns which I skimmed.
I didn't get much out of it the first time, so I watched lectures by Kent, Uncle Bob (Clean Code) and Ian Cooper (TDD). Then I went back and read it again and found it to be excellent.
For more TDD examples with code, there are many TH-cams in Java, Python or C#.
If you still do big upfront design with UML and need to develop a system driven entirely by User input, and want to transition to Tests Driven Development, DbC could be a good intermediate step.
However, it directly models real world Roles with Classes which I think is problematic, and also assumes that the Users will want to write behavioral tests, whereas they actually never have time to red them.
I think this is well worth watching - it certainly gave me a lot to think about - but before attempting it, I would review Allen's more recent output to see if he even still advocates DbC and if so, what changes he's made to it.
Personally, I don't see a need for this front end to TDD.
I guess I remain the weird one. I don't want to read your code, no matter how wonderful and beautiful it is, to understand how it works. Give me your API docs. If I have more questions, then perhaps I will read it. I should not have to read your damn code to use it.
I'm not sure I'm a fan as much as I am intrigued by some of his ideas.
"Growing OO programs with TDD", "Junit in action", "TDD explained" also look into design thinking, look a the criticism of SCRUM
If you have test suite, arent they better than the api docs or serves even better(just my thoughts)?
The interface is the API docs. You have the type signatures and you can add javadoc style comments on every definition. There you have the API docs. You don't need to read the actual implementation. Nobody wants to read implementations in order to understand how to use an API. This is what Allen is trying to point out.
You misunderstand entirely. He's talking about the interfaces, which are in fact code. You can generate an API doc from the interfaces if you want to read it that way, but it is still design by coding. You can even write out the interfaces and then write the acceptance tests first before writing implementation: both writing interfaces and writing acceptance tests is "writing code". That's the "design by code" Holub is referring to here.
Read the sub-title of the talk: extending TDD and BDD into a design process. He's saying design by writing acceptance tests, interfaces, and behaviorally-driven unit tests first.