Test Driven Development Tutorial For Beginners

A general query, would you consider it a bad practice using in-memory DB instead of mocking the DB interactions while doing TDD?

Very useful to see you thinking the process through, and the common mistakes. One aspect that I think is worth separating out - especially for beginners (I'm trying to find collateral to help an actuary get their head around development) - is the background on 'separation of concerns'. The emergent design may come over as too complicated to understand quickly

Always painful to watch someone typing slowly code char by char and explaining things for half an hour, which could be a 5 minutes video.

where can I see more complex example of TDD practice being followed? This one is quite simple as there is no interaction with external api, no dependence on DB, no multi-class interaction etc.

this was great!

Anyone interested in this stuff should ALSO check out anything by JBrains (J B Rainsberger). Dave and JB are a fearsome duo!

That's the kind of videos i love, it very instructive to have tutorials of such advanced topics from someone as experienced as you. because all the tutorials nowadays focus on technologies and tools rather than software engineering best practices.

Even-though I'm an experienced programmer I have done very little TDD and never really missed it. I'm open to the idea but and I get the theory and it works out well in simple cases like this. The problem I have is that so much code isn't testable. For instance user interfaces, code that assumes certain large data-sets. Just to name a few. You end up using fake mock-ups and fake data. I've seen people going into great lengths doing it and in the end they have tested absolutely nothing real. The code may be fairly bug-free but hey, they spent 3 times the time on it. That time could as well have been spent fixing the one or two bugs. Well, I'm just one of those people who values practical real-world situations over theory.

gg

"Experience is a hard teacher because she gives the test first, the lesson afterwards." – Vern Law 😁

My problem with these exemples is that it's always trivial examples. Can't we get examples on things that are more akin to real world ?

Thanks for this nice introduction to TDD and making me aware of cyber-dojo, a great resource! As a TDD noob one question is should I create tests for input parameter validation ie checking the values passed to my code are in the correct range etc? If this shouldn't be tested as part of TDD where, if anywhere, should that be tested?

very interesting - the small moves ... thanks!

always copy-paste variable names; type once - copy-paste many! ;-)

I tried cyber-dojo however it does not seem to recognise ES6. I get your point though so am practicing using VSC.

Shouldn't it be "Test-Driven" with a hyphen?

I understand the basic steps involved in creating a failing test and then doing enough implementation code to make all the test pass. However, the code refactoring after having written all the test is the tricky part—this involves careful design of the system.

How is this a "Tutorial for beginners"? Too many prerequisites are not addressed, in my oppinion.

TDD seems scary, hard and slow to those who don't use. But once you commit to it, you'd be like "what have I been doing all along without you?" 😂

I do love your "to the point" approach. "blah blah .. the rules I just described". Too many love the sound of their own voice in overly padded videos. That said , multiple return paths are fine when you can read the code clearly. Single returns frequently cause way overcomplicated logic bracing.

It's pay now or pay later. I admit I've never done this at it's purest form, however once I had the opportunity for a client BA giving us the inputs and outputs for a particular system and while he was doing this I thought to myself that I could finally do some TDD. It went great! There were 2 glitches found: The first was a scenario that the BA left out and the second was when a developer wrapped my code and did not do TDD on his wrapper. (i.e. my code behaved as expected!)

I just posted this in my team’s dev chat

Very helpful! Would love to see more.

D language has unit test support built in to the compiler, which in turn motivates us to really write the tests instead of adopting any complicated setups.

where did you get those glasses? great video by the way

I need that shirt! ... Also great video!

I would love to see more tutorials like this or courses where you build a full project with TDD!

David Farley, keep up the good work :)

I think you hit the nail right on the head: the hard part is being good at design. So here's the thing: can good software be created without TDD? Can bad software be created with TDD? I believe the answer to both questions is "yes". With this in mind, therefore, is there too much emphasis on TDD? I think yes. I don't believe that TDD is the panacea that we'd like to think it is. In fact, TDD has nothing to do with good software design, and thus well crafted software. It has become a mantra - which brushes good design under the carpet.

Good tutorial, I finished the exercise although I don't think I was able to make such small steps towards getting fails, greens and refactor small portions of code, but I did manage small functions that allowed me to test things like isMultipleOfThree method and isMultipleOfFive first failing and then passing. Thank you !

I have done embedded firmware development for 30 years in C mostly...and cannot for the life of me understand the confusing metaphores( dojos,antipatterns,etc) when trying to understand how to employ TDD in embedded work. Way more confusing and complicated than necessary. Are all you Gurus just working on coding websites in Python? Your tests still look like you are writing code so what is the point when you still have to write the code..more code more mistakes. More pseudo techy koolaid that I can’t justify drinking. Can’t see trying to do this for writing stepper-motor- driving code.

I would like to see the second part

I used to develop multi-yeared projects as a hobby. After years of experience, I can easily say testing is vital to any project. Recently, I made a craeer shift and started working as a senior software engineer in a local company. In the first month, they've asked me to drop all the different types of tests I was writing and only write functional tests for APIs endpoints. They will pay the price of faster development in the near future 😅

Now the second part is released it would be useful to have a link to that in the show notes :-).

SAVED!

Showing TDD with python, you should have picked Pytest as a proven standard :)

More TDD cookbook videos please.

I am a baby developer (just started 3 months ago) but I naturally started doing exactly this. I think it is great not only for catching early errors and mistakes but it also deepens the joy of creating a functional code because you get the feedback so frequently.

The important missing step is how to go from hard-coding a test and fix for each case to a fix that is a more general solution to any conceivable test.

Part 2 please!

Great advice! I would have liked so see a bit more about the transition in the code going from simple cases to the general answer. Following the absolutely simplest approach that you mention, we test 2, then 3, then 5, then maybe 15, and at that point we have an implementation that is effectively a lookup table of the correct answer for our test cases. Each time we add a new test it seems that the simplest thing to do is to add another if check that just outputs the correct answer for that specific test case, which brings us no closer to actually solving the problem. I'd love to hear your perspective on when/where/how we transform a lookup table of answers into a solution that works for a general input. Is this the purpose of the "refactor" stage you mention?

18 minutes in I suddenly realise it's TDD, not BDD (which is what I want to know about!)

This is a great video. Thanks again.

One value of TDD is the ability to keep only one thing in mind at a time...

red - specifying what a thing ought to do
green - do the thing
refactor -- improve thing and tests

BUT... something great from the original TDD by Example book that I think is one of my favorite things...

the "TODO" list.

As we think of things (design related, test related, etc...) that we are not currently in the process of doing we can write them down to keep them out of our heads.

so the todo list may read (in comment)

- test 1 returns '1' - x
- test for 3 - x
- test for 5 - x
- refactor for single return path?

Just wanted to share one of my favorite parts that I use constantly as I practice TDD. I feel like it helps me produce better software design - which I hope someday lives up to what I regularly see on your channel and trainings.

Thanks again, Dave

As a big advocate and teacher of TDD, and an interviewer of candidate engineers for my teams it always amazes me just how many people claim to do TDD but don't actually have a clue. Even then the difference between good (useful) TDD and poor (fragile) TDD is a big gap. Once the penny drops it is normally plain sailing and any tool that supports that good behaviour has to be a worthy addition to the toolbox to get everyone across the line in a shorter time scale. Doing all of this in practice tends to be the big bugbear though, where TDD skills blend with unit testing and people go back to old, bad habits just to get work done rather than follow the path and make sure the code output is built the right way

Another interesting video Dave, thanks for sharing. Hope that cold's all cleared up now!

You made a little mention in the video that I found really interesting - that you don't like many return paths from your functions. I wonder if you could expand on that sometime with an opinionated piece around functions and returns? For myself, I use "early returns", "guards", or whatever people like to call them as a way to keep processing to a minimum during execution.

As always, TDD is a practice, doesn't necessarily means you must follow it.
In my experience, TDD is quite difficult to apply because the codebase is so old and I don't have the necessary business knowledge and logic to do the TDD. Hence, sometimes we create the test after we do the code.
It is also sometimes quite difficult and tedious to change the code very often when the project is quite agile, which cause requirement often change in the middle (sometimes after you finish the test and the code).

It's nice to use TDD when you own the codebase, know well what to build and you have clear concise requirement which makes the test very easy and simple but this is quite rare in some part of software development IMO.