When Test Driven Development Goes Wrong 

-- Anti-patterns -- 4:03 - The Lair 5:52 - Excessive Setup 9:54 - The Giant 12:57 - The Mockery 16:22 - The Inspector

Gotta steal that sentence, "If our tests are difficult to write, it's telling us something about our design." Yeah. Exactly. That's what I observe, too. Over, and over - and over again. When we end up with a test setup of 72 steps and a teardown of 90 steps for a single database update, that's not a test problem.

My university tried to teach unit testing to us by giving us already written software and asked us to apply unit tests to it. At the time I remember hating it because it was mind bending trying to get the tests to work due to the ridiculous amount of coupling meaning stupendous amount of setup. I didn't at the time really understand why I was finding it so hard but I knew something wasn't right. I couldn't imagine anyone would do this in a job and there had to be a better way. The tests that me and others designed got to about 80% coverage and that was seen as acceptable for assessment - it was probably impossible to go much higher. More than a year later they reintroduced the the concept of TDD (sort of) in a module called advanced software concepts which cited Martin, Fowler, Beck and the Gang of Four but it was all just piled in together - not making it clear how each part fit with the others and that TDD is basically the lynchpin to all the other ideas or emphasising the importance of the cycle and fail first. It's no wonder enterprise doesn't know how to implement it. The way this was all taught almost made me not want to pursue work in the industry if this was what even some of my days were going to be like.

0:00 - Intro 2:39 - TDD 4:03 - The Liar 5:52 - Excessive Setup 9:51 - The Giant 12:54 - The Mockery 16:19 - The Inspector Amazing video with excellent points! I made some timestamps for review.

One of my first experiences with debugging someone elses test, was a test with lots of mocks that happened to fail when I improved the code it was "testing". I moved an expensive repeated call to a procedure on an argument from inside the loop to outside the loop; as it was just recalculating the same value every time anyway. The test then suddenly failed because it expected it to call that procedure 8 times and got only 1. Once I managed to understand the "test" it turned out it mocked the database, the message objects and the webserver etc. and the only part of the actual code it were actually testing was that the loop were written inefficiently. This is the main issue I have with TDD, or at least "mock TDD" is that when I'm working with projects that have lots of "tests" written by TDD-enthusiasts (that rarely understands it) is that the tests often don't catch bugs, it just enforces existing bugs; so almost always when I cause a test to fail when refactoring it turns out the test was asserting bad code; and when I actually introduce bugs it normally passes just fine because the "tests" mostly just tests that the mocks mock and the fakes fake and very little else. So many articles about "TDD" just wastes so much time on fancy ways of mocking the entire environment in order to have "test coverage" rather than just assuming some parts of the environment should just work.. If you're not making a database, just using a 3rd party database, why would you waste your time testing that SELECT selects and INSERT inserts? If the database doesn't do that it's pretty worthless, and even worse testing that a mock-database mock inserts when you ask it to insert something is just stupid. If the code you're testing simply takes some data, validates it and forwards it to the database; just test the validation if it's complex enough to warrant it, and don't bother testing the database. I've also seen "unit tests" that test getters and setters on message objects... wtf? Are they trying to verify that language features work? That variable assignments assigns and return statements return? Are they even aware that the testing framework is written in the same language and presumes those features works in order to work. And even more stupid, is code that basically test getters and setters on a mock objec.

This video is gold, as usual in this Channel.

Deming said it (maybe) - "when a measure becomes a target, it stops being a measure."

The most annoying thing of developer with tdd is there's some that has become so (falsely) over-confident of their code because all their test case passed that they use it to (wrongly) argue that the fault is not in their code while more often than not it is..

Clear, practical, not dogmatic. I like it. And I like also that Dave considers there is some design before writing the tests. TDD is not an alternative to design - the tests actually validate the design before implementing it.

Having bad tests in project that pass reminds me of that meme where dog is sitting inside a burning house and saying "this is fine"

This is what I am saying as well when I try to encourage taking up TDD. That TDD is not about ensuring that you have good coverage or some such. The main benefit is that it gives you feedback on your design before you have spent lots of time implementing it. If your design is hard to write tests for, its probably not a good design, but since you didn't yet implement it, going back and improving the design is cheap. TDD is a way to test design in addition to code so it pays off in better design, better tests AND better more error free code.

👏🏿👏🏿👏🏿 Not a heavy practitioner of TDD here however even I did see those mistakes over and over. This is gold, on top of gold on top of reflection & care. Thank you !

Dave, as someone living somewhere without much access to information like this, or not surrounded at all by developers, I greatly value this videos. Thank you!

This was my first viewing of this channel. I am excited to see the rest!

Nice video. A suggestion, when you put code on the screen, please place it in a way that is clearly visible.

Learned a lot that I can apply in my work. While doing code reviews I often have difficulties to explain what I don’t like. A list like that is really helpful!

Love your videos. Really makes so much sense after getting a bunch of real world experience. So much rings true.

On the Inspector anti-pattern. I am a nuclear physicist and are developing a large scale simulation code for atomic nuclei, and I do use TDD. However, in my code I have functions that produce transformation matrices which can be very large (with very large I mean that they can take several GB just to store the non-zero matrix elements as single-precision floating point values) in production code, so naturally I need test cases that cover these larger cases. The problem is that because they are so large and that I need to check very many versions of them it is unpractical to store examples of each and every test case, so instead I need to check that they fulfill specific mathematical properties. However, in the production code there should never be a need to check these properties, since it would be a waste of expensive computing time to check it in production runs when it should be guaranteed if the code is correct. This means that the code to check these properties are specifically written for the tests and only used in the tests. This to me sounds like what you describes as the Inspector anti-pattern, but I don't see any practical way to get around it. Other than that I think this is a great video and I really think that I learn good stuff from all your videos, so thank you.

Hi Dave. Great video, as usual. I’m a big fan of yours. Just a note on the public method to get the last build in Jenkins. I use Jenkins quite a lot and it’s far from being perfect. However, in the specific method you couldn’t find in Jenkins code base, I just wanted to mention that Jenkins is heavily based on plugins, so that method it’s very likely exposed to allow plugins to get info about the last build. In fact, that’s even useful in scripted pipelines (accessed via Groovy). Once again, thanks for your work and knowledge sharing!

Fantastic stuff Dave!!

Any time you find yourself using reflection in tests is also an Inspector symptom.

I am shocked at how spot on the symptoms and causes of these anti patterns are. Well done you read me like an open book!

Great video! Many of the pitfalls explained here are due to not using a TDD approach. I would love to see some advice for developers tasked with adding tests to existing projects that were not originally developed with TDD.

Thank you for sharing. Your experience is very valuable. Specially for us entrepreneurs who not always worked for big organizations before.

Extremely insightful, thanks!

Hi Dave, I'm a fan of your videos, how you explain things and I absolutely agree with you on every point that you made but I don't believe TDD only brings good things. TDD is a very valid technique and I think every developer should at least know it but let me point a few things out that most people do not consider when they talk about TDD. 1 - Test is a code designed to test another code. We cannot expect that by writing a test we will automatically make the production code better. If tests are going to help, the first requirement is to be good at writing code. This may sound obvious but my point is that not every developer writes good code and in a situation like that we would be better without a broken or useless test. 2 - Your test will be as good as your requirements. Obvious again? Yea but when was the last time we saw solid requirements from the beginning? Requirements tend to be fluid (at least in the first stages) making most of our tests useless every time they change. 3 - Tests can make future modifications very expensive. How many times did we add a feature to a software in a couple of days and spent the rest of the week fixing tests? I know that is not supposed to happen but it will. It could be because the managers don't give enough time to deal with the tests properly or because a new developer was just hired and he didn't fully understand what the test was trying to do. 4 - Tests don't always affect the production code in a good way. It is very common to see developers separating the business logic from the provided apis. That makes the code very easy to test but it doesn't necessarily improve the design of the code positively. 5 - Around 80-90% of our systems will be automatically tested if we use frameworks. Hibernate? Spring? Vaadin? We don't write as much logic as we think we do. If we are using Spring Data/Hibernate/MongoDB we are not even writing our own queries most of the time. We don't produce endpoints in our RESTFUL webservice when we use Spring. When we do this, we are using someone else's code and this code is already tested. 6 - Extensive testing is expensive! It takes a lot of time from developers, time that could be used on the production code. Creating a toy application using TDD where we can easily spec all the requirements from the beginning and don't have to support code from other developers is very different than having to design something in an enterprise environment whilst the requirements are constantly changing, I'm sure you know that. I hope you don't think I'm trying to discourage the use of TDD, that is not my point, but it is clear to me after more than a decade as a software developer that TDD is not a silver bullet. It is a fine technique that may help developers in some projects but it is not what will ultimately define "good" or "bad" code. That usually lies on the skills of the developer despite the number of tests, we all have seen great code with no tests and bad code with lots of tests. Writing good tests is an art and it is not easy. Personally I don't care what technique was used to produce the code as long as it is well designed. My opinion is that every developer should try TDD, but they also should have the choice to use it or not. What REALLY matters at the end is the production code, not the tests.

Wow, just found your channel and it's really been amazing!

I really enjoyed the video but I think that the Jenkins example was unfortunate. By transforming the functional test on Jenkins into a unit test on JenkinsUrl (or whatever the class name was) we’ve also moved from testing the requirement (“Jenkins should not have the word localhost in its url”) to testing an implementation detail. I’ve experienced times and times again that implementation details like these are not actually used in the use case I was working on (in the Jenkins example, what guarantees do I have that JenkinsUrl is actually being used?).

Thabks for sharing your experience... This clarified a lot of doubts for me

Pure gold. Thanks for this

First thing first, that t-shirt is very cool and I really want one now. Yes, priorities.

The most powerful important statement that really slapped me... "Testing is a tool to achieve an outcome".

There is one case when complex setup is unavoidable, IME - when you test stuff that's strongly coupled to framework interfaces. Strongly coupling your code to the framework is often a conscious tradeof for lower development effort. There are also tests that might look odd, but are actually legit - tests you add late, as a reproduction of a bug report.

You had me at SKYNET! Yet another awesome vid thank you for your great insight.

I often found myself in the situation where I wrote tests for classes someone else made long before I even saw them. So while this advice (which boils down to "use actual TDD, not fake TDD") should work, it's not always a possibility. Although, if you're sitting down to write tests _because_ you struggle to understand what the class is supposed to do, maybe you're not the right person to write them.

I'm not a huge fan of TDD and writing tests first. I do write test first but they usually don't evaluate any correctness. They are just a way to drive lost of test data through the system so that many codepaths are run. Then i use DesignByContract (yes one decade in the past i was a heavy Eiffel user) and the code itself contains the test in forms of assert statements. Tons of asserts. And invariant statements. I find this much more efficient and helps to write more quality code.

From your other videos, I know that you are well aware of Eiffel and perhaps even Design-by-Contract. I wonder if you would speak to TDD in the context of Design-by-Contract-OR-better yet-do a video on TDD + DbC. It would be interesting to get your take on the good, bad, and ugly of TDD + DbC.

Hmm, the software company I work for has a 30 year old codebase and we recently switched to C# based unit tests. I see what you mentioned about writing the code before the test and indeed we have many tests that are giants. However, at this stage, you almost have no choice in some areas because you might need to test some functionality that is dependent on another functionality. At that point, I have to test both in one test function. Despite that issue, I do think writing the tests has helped me improve areas (including code I previously wrote), so I agree with your initial statements about TDD.

Who is this guy??? He's making my life easier. I need to buy this man a drink or two

Some real gold in there Dave. Thank you! This is why I prefer the term "test driven design" over "test driven development" - it emphasises the value as a design time activity. I worry about that those teams who, with best intentions, introduce metrics like minimum test coverage % without first training teams in the art of design.

Good piece, much along the lines of Vladimir Khorikov's excellent "Unit Testing" book which explores these topics in greater detail.

Minor correction: the getLastBuild function is indeed not called in the production code but it is still used productively. The user can call it themselves in the pipeline which can be quite useful. The point about the inspector anti-pattern still stands. It was just an unlucky example.

Hello Dave. Thank you for another useful video. I believe many coders do not understand test-first strategy. When people are being taught TDD most examples are small and academic and focus only on teaching the techniques but do not explain the value (the why). My personal opinion is that TDD/BDD is not as popular as it should be because many are missing knowledge that "product development steps have to be designed top-down backtracking value and asserting it on every step of the work breakdown". As long as coders/developers are micromanaged and given individual tasks all of BDD focus is lost and all of TDD benefits will not materialize. I am also heretic - my testing code stops at integration layers - I do not want to write unit tests for individual methods and classes as it is too fragile approach - I believe that only value of public interfaces/methods of packages or modules or services has to be protected - that means that all valid usage scenarios need to be asserted via tests and having coverage is probably lacking assurance that all of the value is delivered. I have never seen proof that more granular value assurance has any meaningful ROI...

Great video! Quick question for 11:38 , if I have an object returned from a method, and it has 3 or 4 publicly accessible members, you're saying even though I'm testing the same function with the same input they would be different unit tests per member? I've never thought about it that way but I will try it out. Also, would you say using something like assertj's assertAll takes care of the issue?

Hi. Just discovered your channel. This is the second one of your videos I've seen. Question: Most of what I do is text wrangling. The string(s) I am finding, deleting, replacing or changing tend to be unique to each document, and there may hundreds or thousands of documents per job. I have looked at a lot of testing tutorials but have not found one that shows how to test in this environment. Suggestions? Thanks!

Ports and Adapters / Clean / Hexagonal Architecture help a lot with the separation of concerns and therefore making your system testable.

Excellent video! I'm definitely a fan of TDD but have found it very difficult in certain contexts. One particular example is writing a manipulator/gizmo system for an editor. There are a number of complex factors that I found made writing the tests first difficult. The first is that all interactions happen as mouse events and things like position in the 3D world and distance from the camera cause the same 2D cursor delta to produce a different result. We really wanted to test this (we didn't have any tests before 😬) and wound up having to write a test framework API for manipulators doing projections from screen space to world space and back. In the end we got some decent coverage but it was a big investment. I'm curious what your advice would be for TDD when it comes to these types of interactive applications (editors, games etc...). Also keep up the great videos! 😄 I loved the one on (not!) branching 🙂

I like when people make private methods public to be able to test. And usually if you want to do such things it is telling about bad separation of concerns.

How do you write the mininum amount of application code to make a test pass but at the same time not couple to implementation?

we implemented TDD for Backend code around 2 years ago and are very happy with this. On the other hand for the frontend we ditched it we are allways writing the test afterward the reason is simple, Objects there change much more frequently, as a quick example is that we sometimes just dont know if a checkbox(boolean) or maybe a textbox(string/enum) or even a dropdown(array) is the best way to approach an problem (on an ui/ux friendly way), so it would be a waste of time to write the test beforehand.

Very valuable content!

Not organizing code by use case tends to make it necessary for everything to be public, which in turn allows the test swamp to be created.

Great video!

After watching this video I have one question though about the "Giant" (10:00). How about initializer functions, that set up objects to some default/empty state? I would write a test with a single line of code ("Something s = new Something"), but then add a lot of assertions to go through all the possible properties and functions of my object and check if all are in the way they should be by definition. Would that count as an instance of the "giant", and if so, how would you improve on this?

Great video. Thank you so much! I have a question please: at 9:20, say that I did not think of an edge case while writing my test for the first time, would it still be easy to add an edge case say 1 year later? (for the sake of argument the same exacmple you gave)? I am still new to TDD and I am asking myself how can I not complicate my test if I want to add another case to it after a while if I forgot it? What if a piece of code which already has a test changed later and thus my test need to change? for example, that method you showed at 18:58 .. suppose that method was really in the code base ( was added later ) .. shouldn't my test case adapt to these changes or should i "refactor" the whole test case from the gound up? I dunno it might be a stupid question but I think you also need to be very good in abstraction to think from the very first beginning how a function, for example, should behave right from the start, no?

That Skynet tshirt is epic dope!

hello at 20:02, can you elaborate this idea on some concrete example, pls...

"The Mockery" hits the spot for me. I have seen this pattern on a few occasions. I was working on some bugfix and did refactoring in the code base. I also identified some tests for this area. After analysing the test code, I came to the conclusion that this test provided almost no value. Everything was mocked, and the mocked elements, was all coded to “emulate” the production code. It felt like nothing of the “real” code was tested.

Agree, but you need to have a really good BA to ensure the user acceptance criteria are clearly identified and fleshed out, plus bring in a really good tester for the 3 amigos reviews to identify whatever else should be included or categorized as part of the integration and smoke testing requirements.

This rule about not breaking encapsulation makes me wonder. I think I get the point. The methods or object should be testable without seeing its private members. You can assert that it returns correct values without digging in its internals. However, I can think of situations where I would like to test private members separately. E.g. I have a class that contains an array of private methods that calls each other. Each method perform some simple step to achieve much more complicated goal at the end. In this case I would want to also have tests for some of those partial results not only for the public members. Testing the whole object may tell me that something has broken inside but I'd still have a lot of work ascertaining which exact method has stopped working.

And now for those who work with microcontrollers and external hardware like stepper Motors without feeback? What should I do?

I have so many questions, even though I have practiced TDD on several projects. What do you do on mathematical calculations? I usually test a few known inputs and outputs but that seems to follow two of the anti-patterns you mentioned. The Liar and the Giant. I am just doing a test for the sake of the test and I am also having multiple assertions. FYI the calculation is returning a few values so I need to test all of them that they give the right result. I am also testing some extremes, i.e. x cannot be zero and throws an exception. Should I test the behaviour? i.e. when x is rising y is reducing? That seems too vague for a unit test and if I were to be super specific, I am just replicating the actual code...oof...

Still laughing at that bell at the very end. I feel like it’s a fundamental aspect of your videos, and I would be saddened if it were ever removed.

A very useful tool for selling TDD to dev teams - thanks :)

Thank you for this video, and for your advocacy of test-first TDD! I would like to respond to the antipattern of the The Giant. At my work, there's a legitimate use case for writing such tests to cover the top-level expected behavior. We have a service that has to process multiple messages of type A, B, C in some particular orders, such as A, or AC, or ABB. Some of these common permutations deserve a "The Giant"-style test, to express the behavior expected for that use case. I am not saying that we write these "The Giant"-style tests for each permutation of _all_ of the underlying behavior - for that there are smaller tests of the underlying module(s).

Great video! I was pondering on some issues I've had with 'table driven tests' most notably used in the Go source code, and generally percieved as best practice for Go. What are yours or anyone else watching this opinions about them? For me, they seem more suited for smaller methods/functions which doesn't require mocking repositories or database interfaces, and for more complicated codebases they tend to produce really hard to read and understand tests. I've so far opposed this practice, but I have had no choice but to adopt it as well as that is the convention in my current project, and I've struggled to convince our team otherwise. Perhaps anyone shares my opinion, or perhaps this is an issue with the codebase itself (e.g. complex input/output for systems). I prefer writing one test per test-case rather than one test with an array of input/expected output parameters

I watch Dave's videos partly to see another brilliant T-shirt

The problem I have run into is how do I test code that depends on large math data structures without having a fair bit of setup? For instance I was doing work on a solver and it takes in a 4D array that is several GB in size. While I can make it much smaller that also ends up not testing the solver correctly due to the error it introduces. Saving the data structure to disk can also be a problem in terms of then trying to keep it with the code and not having the checkouts be too large. What I mostly end up with is a complex setup for some of these kinds of tests and also separate tests for every single piece I can test independently.

How do you deal with overcoverage, especially if the test is not redundant? It means that some earlier code may, if changed, require hundreds of tests to be changed and re-examined for a single api change. This is most serious in the case or updating to a v 2.0

This is a top video, really useful. I have one question please - what is meant by encapsulation in "The inspector" ? I've seen some definitions that basically say bundling of data with the methods that act on that data. Therefore "violating it" means creating methods that only exist for the purpose of testing? Am in the right ball park? Also does encapsulation only refer to OOP, as most searches I've found on the term seems to suggest this. Thanks!

Another of those videos that you would like to “like” more than once.

I'm trying to find the blog post written by James Carr, but his blog now points to medium.com (blog.james-carr.org/). His medium.com page doesn't have a post about anti-patterns. I found the archived version here for anyone that wants to read it: web.archive.org/web/20100105084725/blog.james-carr.org/2006/11/03/tdd-anti-patterns/

I've been wondering if theirs anyway to realistically create a universal test Context for all of the test setup for code? I assume that it could be down at a smaller level quite easily. Although I guess if you have a universal test context this probably means that the code is too coupled? I have sets of classes that often interact with each other through events and find myself practicing this concept at small levels to keep an organized setup.

There's another factor I think I've found to be at play - engineers simply not being very comfortable with their testing tools. I've been a TDD evangelist everywhere I've worked and almost without exception every engineer's objections to TDD have evaporated as soon as they were given permission to really study how to write good tests and practiced doing so. I think the excuses and combativeness about TDD is usually a front for insecurity about a skill they lack.

I like this, just one observation. Many of things are true and fixable whether you use TDD or not. Being able to write testable code is down to not knowing how to write useful tests to begin with. Too much setup and mocking is a problem that can be seen as solved with or without TDD. At the end of the day, this is useful for anyone who doesn't know how to write useful tests

So, if I write a program to add two numbers, attempt to write tests around that addition program, but have trouble doing so... the reason for my trouble is that I wrote my addition program to add, and not to be tested. Is running the program not a test in itself? Can you imagine if Ford built a mold for every individual car, before it was assembled?

Thanks for the video =)

Excellent content

About "The Giant", when test team and development team is two different teams, it happens all the time and it does not harm as much, when you test against requirements, please correct me if I'm wrong :)

I feel like a lot of programmers get that the design is bad and the tests are difficult to write because of that. But what if the bad design is just much too large to refactor along with doing your actual task and writing tests for it? How do you tackle those kinds of problems?

What are some good sources: books, courses etc on how to actually write tests before writing your code for devops? Thanks

tests make no sense until the solution to the problem and the at least rough design is clear and understandable to the programmer. I program according to my alpha - beta - done - method: I have many tested modules close at hand in my private library alpha: I play around with the rough edges of the problem, the data and methods of which are not yet clear to me, until I no longer have any questions regarding the content. So if I start a program that doesn't behave as expected and I spontaneously have no idea what the reason might be, then I don't need a computer, but rather a piece of paper and a pen. beta: this is the first time I test correctly because this is the first time that I can ask meaningful questions about the code, which it then answers correctly or incorrectly. Trivial errors caused by copy and paste, ... I take it out here, these should already have been recognized in alpha. Of course, this can throw me back in alpha again and again in individual modules, but I don't know any author who claims to have written a book in one go without correcting the course of action, descriptions, etc. In short: whether and how I generate a test of my code depends solely on my understanding of the task. And, of course, what I expect from me to do a good job and not waste time creating new problems

TDD is an illusion of quality. Quality is to make system perfect. What means use asserts in the system itself and do it the "right way". In unit tests asserts are just interesting. But never effective enough.

Having played with a whole bunch of different strategies for test automation, I've come to the conclusion that there are certain tradeoffs that are necessary, and you cannot have a test suite that is a) performant, b) clear in purpose, and c) robust under refactoring. I used to be an acolyte of the "test at the class boundary" school of testing, and it was really convenient in that each test case ran in a millisecond, and because the unit under test was small, the test cases practically wrote themselves. Chasing code coverage was a breeze. And then when the time came to refactor the object contracts, we ended up having to rewrite all of those tests. And then I watched Ian Cooper's video, "TDD, Where Did It All Go Wrong," and told myself, "yes, this is what I've been doing wrong!" and I changed my tests to target the "unit of isolation," rather the unit of implementation, i.e. test the whole behavior end-to-end instead of just your one class. It was great, because I could do big refactors without the tests breaking (unless they were supposed to). But then something else happened -- the test started taking longer and longer to run. It turns out that when you tell the Angular compiler to build an entire page on a single test case, your tests go from 1ms to maybe half a second, and a test suite with 1000 test cases takes several minutes to run. And you start having to get economical with the number of test setups. So you start breaking that rule of "single purpose," bundling a whole bunch of checks into a single test case, because it'll save 10 seconds per build, per developer, and that adds up. And now we're at The Giant, as you call it, with no indication of ever going back. I would love to hear one day that there's an approach that actually gets me all three, but I'm skeptical that this no-compromises solution exists.

I purchased your book. Very interested in automation and testing. But I am involved in Game Dev where there is a lack of clarity as to what the spec is (evolving product).

The Liar, very common, yet often necessary when a code base has been abandoned and the new team has to meet standards before rebuilding from scratch and adding TDD as a primary direction.

How would you apply TDD to scientific computing, where the inputs are complex datasets, not strings, and the code is performing non-trivial computations that are dependent on the characteristics of the data?

Answering your first question in this video, well sometimes the owner of the product does not want to pay for quality software... and yet they complain

TDD would be more ubiquitous if it was used to teach coding. As a separate track which can be optional, TDD can be perceived as "getting in the way".

Great video. I will definitely reference your videos during my XP Dojo's. Thanks.

Yay Skynet T-Shirt - is the set complete!! :) Loving these videos - are you able to comment on DDD (I'm not convinced personally - however the strategic DDD parts sound more meaningful in terms of bounded context / ubiquitous language etc.)

Stick a watt meter on the power cable and test for efficiency!

This is lovely advice to write another fizzbuzz or calculator. Most of these tips simply dont fit well with complex systems with lots of procedural code - which is your average Java app -

My favorite style is Giant 🤪 However I find it really impractical to repeat some code only to keep one assertion per unit test. More over I like table driven tests with loops inside of single unit test just to make many tests for the same code.

I wanted to believe in TDD, but I was still hesistant. After all these examples, that I actually see in my own tests... well, now I believe 😁

tdd-first // create a variable to hold the value: 0 // test test("it should hold 0", () => { // variable let value = 0 assert.equal( value , 0 ) }) // implementation let value = 0;

If the code is difficult to test, it means it's design is .... difficult to test. When you switch testing frameworks, sometimes one framework will be a better fit for your design than another. Does this mean that you design suddenly improved by removing one testing framework and replacing it with another? You design for what you want to obtain. If you're doing test driven, you'll want it to be easy to test with the framework you've already picked, so the testing framework will dictate how your code is designed. When you have a hammer, everything looks like a nail. Testing should be in service of your project, not the other way around! Remember every library you pick is already a choice you're making and it will change what the project will look like.

Talking about TDD starts around 4:00. Also, great video!

Isn't TDD built in doing Unit Testing and thus only one thing can be asserted? Isn't a great that tests many things more of an integration test? Developers write unit tests before they write any code and see if fall testers write integration tests for scenarios they come up with whilst trying to break the code. Maybe some devs can write integration tests, but isn't it better to have someone other than those who wrote the code trying to test how it all works from start to end?

What is your opinion on handling the same "case" but with different data or cases? For example, imagine I have a system under test that must handle an input date and do different things based on a specific period and some other flags/inputs. Say I want to test the cases where the input date happens before the period; happens exactly at the start of the period; happens in the middle of the period; happens right at the end of the period; and happens after the period. Imagine I would also like to test different dates for each of those cases too, imagine 2 dates per case. In the above case, would you write a single test that had 10 inputs; 5 tests that have 2 inputs each; or 10 different tests? Based on the above response, what is the correct way to manage the huge increase in number of tests, both in terms of code organization (e.g lines of code, files, etc); naming (what do you do if naming becomes hard when you have so many tests?); and other possible issues that arise?