Getting Started with TDD - Part 2
Vložit
- čas přidán 5. 10. 2021
- What is TDD, what does it take to get started learning to do it, and how should you practice it? This Test Driven Development tutorial explores all of these ideas in the context of a demonstration of working on a simple Coding Kata, called FizzBuzz. It also demonstrates the best place for to start, TDD for beginners, if you want to get started.
In this episode Dave Farley of Continuous Delivery demonstrates the second part in the FizzBuzz exercise, and explores how to test inputs and outputs in TDD. Dave also shows the easiest way to begin with TDD and how it morphs into Test Driven Design, using the excellent practice tool Cyber Dojo. Cyber Dojo allows you to practice TDD in a wide variety of languages and technologies with almost zero setup. Dave demonstrates the use of Cyber-Dojo at the same time as describing some subtle and important aspects of basic TDD.
-------------------------------------------------------------------------------------
LINKS 🔗
Watch PART 1 here ➡️ • Test Driven Developmen...
It is free for individuals to use Cyber Dojo to practise TDD (but not for commercial users) and you are encouraged to make a donation to help kids learn about computers ➡️ cyber-dojo.org
See the whole tutorial exercise ➡️ courses.cd.training
-------------------------------------------------------------------------------------
📚 BOOKS:
📖 Dave’s NEW BOOK "Modern Software Engineering" is now available on
Amazon ➡️ amzn.to/3DwdwT3
In this book, Dave brings together his ideas and proven techniques to describe a durable, coherent and foundational approach to effective software development, for programmers, managers and technical leads, at all levels of experience.
📖 "Continuous Delivery Pipelines" by Dave Farley
paperback ➡️ amzn.to/3gIULlA
ebook version ➡️ leanpub.com/cd-pipelines
📖 The original, award-winning "Continuous Delivery" book by Dave Farley and Jez Humble
➡️ amzn.to/2WxRYmx
-------------------------------------------------------------------------------------
Also from Dave:
🎓 CD TRAINING COURSES
If you want to learn Continuous Delivery and DevOps skills, check out Dave Farley's courses
➡️ bit.ly/DFTraining
📧 JOIN CD MAIL LIST ➡️ bit.ly/MailListCD
to get regular updates, advice and offers from Dave and Continuous Delivery!
-------------------------------------------------------------------------------------
CHANNEL SPONSORS:
Equal Experts is a product software development consultancy with a network of over 1,000 experienced technology consultants globally. They increase the pace of innovation by using modern software engineering practices that embrace Continuous Delivery, Security, and Operability from the outset ➡️ bit.ly/3ASy8n0
Harness helps engineers and developers simplify and scale CI/CD, Feature Flags and Cloud Cost Management with an AI-powered platform for software delivery. ➡️ bit.ly/3Cfx3qI
Octopus are the makers of Octopus Deploy the single place for your team to manage releases, automate deployments, and automate the runbooks that keep your software operating. ➡️ octopus.com/
SpecFlow Behavior Driven Development for .NET SpecFlow helps teams bind automation to feature files and share the resulting examples as Living Documentation across the team and stakeholders. ➡️ go.specflow.org/dave_farley - Věda a technologie
thank you for publishing these two videos. I pulled so much from them. Part 1 was easy to follow. Part two demonstrated that separating concerns generally in involves more effort in coding (but not in testing). If I had a suggestion to improve part 2 I would suggest that there were opportunities to demonstrate more refactoring in the red/green/refactoring that you took. E.g., Renaming 'display' and 'render', perhaps with stronger verbs/nouns, would help us follow your TDD cycles.
Another suggestion: having a solution designed for part 2 ahead of writing any tests or codes misses the opportunity to demonstrate how TDD helps to get to a design. And as you point out, having a design in your head complicated your tests/code from the off.
thanks, again
A super lesson and Cyber Dojo looks great too. Thanks for taking the time to produce these videos.
Glad you like them!
Thank you for listening to our feedback.
Might just be worth pointing out for any newbs that Python doesn't do static type checking so you were able to pass in "render" directly from the test. However, with Java or C# you would have had to create a new class for "render", which would have required you to think a little differnetly about the design.
Or simply use an interface instead of a specific type.
It's great that you are showing here one thing I believe TDD requires, self-discipline to not do much than the cycle requires. You have the design of the "working" code in your head and there is temptation to write it. But we need to see red! And that's the reason I have written working in quotes. We know that our code pass requirements when we first see red scenario/test before and green scenario after we write implementation.
My honest feedback....For the first part I was with you..very well done...for the second part you kind of lost me with these render/display tests. I just don't think this second part was described well enough. I kept asking myself..."what is he trying to accomplish here". And there is a lot of test code being written here to test this fairly simple function, thus making this whole thing seem overly complex and burdensome. That alone would turn off a lot of people from doing TDD based on this video. I completely understand the value of testing and using TDD but I just don't think the "Part 2" video helped the cause of TDD. Sorry I have to be honest.
I think that when it comes to testing the edges of the program where it interfaces with things external to it, like the display in this case, it becomes more difficult to test without using mocks, which I don't think that site provides. Actually I think he was basically implementing something similar to a mock with those helper functions that count the number of invocations.
Even I got lost in display/render part. First part was quite good though
Part 1 was "How to do TDD". Part 2 is "How not to do TDD".
I too found it confusing at first but later realised that he was trying to test only the function that can print upto N fizz buzz. Rendering(Converting a number to fizzbuzz) was already tested in Part 1. What was left here was testing the output count which was tested in the function test_should_display_each_number() and each number is correctly rendered by test_should_render_each_number() by replacing fizzbuzz by a mock(render function) and print by another mock(display function). The code is modular, allowing to inject those dependencies and TDD brings the ability to think this way.
We’ve found that in TDD, when there is I/O that needs to be tested in this way (there’s a separate argument as to whether to test I/O directly ) we, very early on, build some generic test code that had less all of this stuff he’s building on the fly.
Nice video!
Great lesson
Two videos a day, nice.
Thanks, very helpful
Great video!
Glad you enjoyed it
Love it! Thanks for this. This kind is content makes what you talk about in your other videos really tangible and concrete!
I'd love to see more like it.
Especially more about the refactor step.
For example why 'display' is passed in the initializer but 'render' is passed in each function call?
Not really deeply thought-out to be honest, but it felt like I may more often want to choose how to render something vs changing where it was displayed.
I have not done proper TDD so far, fair to say I haven't done any. This and the part-1 seem really helpful.
Thanks. I am pleased that you like it. There is a slightly fuller version of everything together here on my training site: courses.cd.training/courses/tdd-tutorial
It is free, but I am afraid that you have to sign up to access it.
@@ContinuousDelivery never going to miss a chance to learn from u!
Your tutorials are unbelievably helpful, Thank you. Just one question, so If I am creating a project on my own.
First I have the project vision, I do my user story map, then I have created my backlog and decided what user stories to work on
I assume I would first write acceptance tests ?, Then Integration tests and then when I get into more detail the unit tests ?
Does this work ?
It's a hard question. A friend of mine writes just unit tests and contract tests.
Dave, What happened to your fb video?
Btw, I think 6 hours is not too bad.
Had a funny experience with TDD last night. All my tests in one module passed. I tried everything to make them fail: assert (1 =:= 2) -> passed. No chance. I've been using the test suites the same way since months, never a problem. I' was quite tired that time and so was my machine. When I was about to give up, there was a black out. The computer went off. The power wasn't completely off, my LED light bulb was flickering, other neon lights off. Scary. After an hour the power came back and my test failed as it was supposed to without changing the code in anyway. Weired thing. To cut a short story long: I like TDD! Thx, Dave!
Wow, that does sounds weird!
I discovered after I released that I made a mistake in the FB video, the (undated) information from FB that I based my analysis of the failure on, it turns out, was for a different incident, earlier in the year. I think that my FB video is good, and there is lots of good stuff to learn from the incident that I studied, I want to use it, but it wasn't describing the incident that everyone was focused on, and I didn't want to mislead anyone, so I pulled it and published this one, which was my original plan, in its place.
@@ContinuousDelivery Thanks for the detailed reply. All your videos are good and there's always lots of good stuff to learn.
Nice little october horror story! Sure it was not a bad dream ? :)
@@nebukadnezar4431 Quite sure. What I 've learnt from this is that for having production code, I need the tests to pass. For development using TDD, I need them to fail.
How does TDD fit with TBD? If I write the test first, the test will fail. If I merge this into the trunk, the CI pipeline will fail preventing any changes from making it to production until i merge the fixed / new code to trunk. As a practical matter, do you wrap your tests with feature flags, or mark them as skippable until the application code is ready for merge?
You are not supposed to merge a failing test into trunk. The atomic unit that you merge into trunk is code + its passing tests.
@@andrealaforgia tbd requires you check in frequently. What happens if it takes longer than a day to write code to pass the test?
TBD requires committing *meaningful* changesets frequently and your aim as a developer is to granularize big changes into multiple, meaningful subsets. The idea is that you break down your work into manageable chunks along the day. That way, it is basically impossible that a single TDD-ed changeset takes a whole day to write.
@@cdarrigo the whole point of tdd is to take small steps though... he says this often.
The whole cycle is red, green, refactor, commit. If you do it right the whole cycle lasts no longer than 10 minutes approx.
Bonus tip: Always end the day with a red to get you going faster the next day.
How do you deal with TDD when you don't really have any clear requirements?
Well, if you are going to write some code, then you MUST have some idea of what it should do, otherwise you can't write any code! So you test that it does that.
Can't click the Informit link in the description, gotta go old school
That should be fixed now, sorry about that.
@@ContinuousDelivery hah, no worries! Looking forward to December!
Is there any way to make Cyber Dojo validate my solution?
Your tests should validate your solution, if they are all passing, and you picked the ones to capture the kata that's it.
You should put link to the first video
There is a link to the first video in a card in this video, and in the description.
@@ContinuousDelivery thanks, missed that
What happened to the “What went wrong at Facebook?” Video? Was it good?
I was halfway through watching that one :/. Maybe this was supposed to go up first
Very sorry, after the Facebook video was published, I found a factual error, so I have pulled it for now, and released this one in its place.
@@ContinuousDelivery I actually watched it, and I loved it. So now it lives in my memory.
I had the tab opened for some time and when I finally started watching, I decided to share it with some friends half way through. People started complaining that it was unavailable, so I did a quick refresh and never got to see the end of it. :(
Quite interesting that CZcams still streams the video if your session has the right state.
@Volfied I discovered after I released that I made a mistake in the FB video, the (undated) information from FB that I based my analysis of the failure on, it turns out, was for a different incident, that happened earlier in the year. I think that my FB video is good, and I want to use it, but it wasn't describing the incident that everyone was focused on, and I didn't want to mislead anyone, so I pulled it and published the TDD one (which was my earlier plan) in its place.
I'm sorry that you only got to see part of the Facebook video - I am planning to remake it with the correct information, and I would be very happy if you watch it then and share it with your friends.
Thanks for your comments and support!
Where is your video about Facebook ?
I was alerted to a factual error after I released it )-: so I am reworking it and plan to re-release it next Wednesday...
@@ContinuousDelivery thank you 🙏🏻
What is self here? def setUp(self)
It’s how Python defines a function to be a method in a class.
@@ContinuousDelivery Thank you
Omg that shirt...