🚀 DevTernity 2017: Ian Cooper - TDD, Where Did It All Go Wrong

  Visualizações 167,765


2 anos atrás

Registration to 🚀DevTernity 2018 is running:
✅ devternity.com
Since Kent Beck wrote the book on TDD in 2002 a lot of words have been dedicated to the subject. But many of them propagated misunderstandings of Kent's original rules so that TDD practice bears little resemblance to Kent's original ideas. Key misunderstandings around what do I test, what is a unit test, and what is the 'public interface' have led to test suites that are brittle, hard to read, and do not support easy refactoring. In this talk, we re-discover Kent's original proposition, discover where key misunderstandings occurred and look at a better approach to TDD that supports software development instead of impeding it. Be prepared from some sacred cows to be slaughtered and fewer but better tests to be written.

Christopher Pakkala
Christopher Pakkala 8 dias atrás
I'm sorry, I really wanted to finish this video, but I just can't take the stage floor creaking anymore...
Dhaval Shah
Dhaval Shah 9 dias atrás
Loved the talk, hated the presentation. I wished Ian had put fewer paragraphs on those slides. It is almost impossible to read while listening to him and trying to comprehend both at the same time.
Jacob Fountain
Jacob Fountain 14 dias atrás
Tableaux using bic hopi good
Mike Rollin
Mike Rollin Mês atrás
Thanks for sharing this talk
syntaxed2 Mês atrás
It went wrong with modern languages - Over-abstracted shit that solves nothing but pile bloat ontop of bloat.
HtS643KyS6555GxQ3edA Mês atrás
Man that leather squishing sound
c5n8 Mês atrás
TDD is not something you try on a weekend, then bring it to work the next monday, it would most probably be a disaster. It takes dicipline, like, well, any other dicipline, before you use it in real work. Uncle Bob suggest that you spare your time to practice it in your spare time building personal project, and it may take months before you do it in your work project. TDD is an extraordinary skill, and it is expected to see only few people have it, because only people with dicipline can master it.
richard Mês atrás
I'm a mere grasshopper to this Shaolin monk
Mandar Mês atrás
this talk is twice as effective after I have used TDD myself, helped me identify mistakes or incorrect ways of thinking a lot
eimaisklhros Mês atrás
So, if I need to get some specific object(or a list) from the db based on something (ex name, address etc) is it wrong to mock my repository in order to test a certain behavior of what this class does? I have an ETL process where I need to test that my processor(module where the business is focused, the T in ETL) passes a specific object to the writer(the L) based on a specific reader input(the E). What I do is test the processor(not its other 10 -20 private methods, those are implementation details) by inserting a certain object and I assert that the object after the process is the one I need. like input = new Foo(param1,param2) This is where I mock the repository based on my business case. every BarRepository returns "someFooStringBecauseOfFooParam1) result = myProcessor.process(input) assertTrue(result, Bar(someParamsBasedOnTestCase). of course I could use an in-memory db for that...I just find it easier to create objects based on scenarios I want to test..
Nomas Prime
Nomas Prime Mês atrás
Ian's argument on mocking is less applicable to verifying mocks. Verifying mocks improve performance giving faster feedback, especially on larger suites, and scalability. There's still a chance that the response from the mock could be incongruous but that's mitigated by tests on the collaborating class and higher level tests, eg, integration.
Nomas Prime
Nomas Prime Mês atrás
Dirk Knight maybe you want to reread my comment, that’s what integration tests are for :P
John Dunlap
John Dunlap Mês atrás
IMHO: Test driven development usually fails because it is too expensive.
AlexXx Mês atrás
Top-town vs bottom-up testing.
Qeith Wreid
Qeith Wreid Mês atrás
Great. Really clear. Thank you.
Colin Mês atrás
You know this is a good video when you look at the like to dislike ratio with the maddening creaking going on through out the presentation
Cryp!0G00n Mês atrás
Fantastic talk!
Inspirationfree Mês atrás
Yes. I was that guy that felt TDD was good for Junior Developers but not really worthwhile for experienced Developer. I still think that TDD is broken, just like I think Agile is broken, and it’s mostly because too many people have taken the term, extended and change it for their own purposes. The bloat attached to TDD for most organisation has caused delays, complications when refactoring, and in many causes shown no reduction in the number of bugs found in production. I still write tests, but they are very high level, and as such my test code coverage is well below 50%. As many methods are use to support a single functional requirement, and I’m only interested in writing tests for functional requirements, that was documented and agreed with the client. No client want to see your tests or a test report. Otherwise Microsoft, Oracle, Google etc would ship a test report with every product. The fact that they don’t tells you everything you need to know.
To Cu
To Cu Mês atrás
Be conscious of right abstraction level. And the key is to identify, properly, your 'unit' under test.
Mark Liversedge
Mark Liversedge 2 meses atrás
"20 to" *speaks quickly* "50 percent slower"
ABC XYZ 2 meses atrás
The thing that destroys TDD is well, TDD. Different tasks in programming have different difficulty and criticality. TDD tends to be implemented as do all the things all the time. Unit Test everything, Behavioural test everything. It's extremely expensive and at the end of the day you can do all of that but when it comes to sitting in the car, putting in the key and starting the engine nothing happens. A lot of these methodologies mistakenly derive from standard that might make sense if you're making the Java Standard Library or face similar specific problems. For example, SOLID taken to an extreme might make sense when releasing a library that people aren't expected to modify but needs to cater to every possible need out there. The overhead doesn't pay off when it's for an end product where you can reasonably posit the use cases. TDD sort of does things backwards and it's risky when the last step is the working code. In practice many people will end up writing the code first, then bolting on the tests as an often pointless exercise because otherwise they'll get fired. Those tests will be the most that gets the least. As an experienced programmer and also a reasonable one I've tried to explain this to people extensively and they just refuse to get it because of some sense of social obligation. The disturbing thing is that when you have the I told you so moment people still refuse to budge.
ABC XYZ Mês atrás
@To Cu The thing you don't seem to understand if that you're speaking to a fully qualified full time programmer both practised, studied, proven and experienced. You tone and insistence on a topic you do not know at all is disrespectful and appalling even if you were talking to a newbie. You have no idea what you're talking about and your conceited attitude stinks. You're dictating the marketing material for TDD and making assertions that aren't yours to make. It's abundantly clear that you do not speak from in depth experience as you repeatedly resort to making statements as though fact which are in fact opinion. Seasoned programmers wont tell you this as we tend to avoid people we can't stand instead but we absolutely hate your type and couldn't possibly get far enough away. I would surmise they're borrowed opinion lifted from some blog or pop programming celebrity. It's not for you to mandate what TDD is meant to do. If I'm rolling out TDD whether as a lead, senior or merely a programmer I'm the one who knows the lay of the land, I'm the one who knows what problem it is I'm solving and I'm the one that says if the use of TDD is to assist with a structural issue, training issue, quality issue, requirements/specification issue or come other deficit. This isn't a matter of disagreement. I'm telling you how it is. In my position I weight up the benefits. If you want to learn about programming then you'll have to swallow some hard pills. I'm the one who says what TDD is doing not some pissant. You don't get to tell me what it does for me. I can however tell you what it does for other people because I have seen it over and over. You ask what is it you do instead? TDD is extra work. You're already doing the instead. Simply drop the TDD. If you personally feel like you need the ramp or want to try it just so you have a familiarity with it under your belt for your own learnings that's your prerogative but it's not appropriate for normal programming. You do not have the strong position. What you promote incurs a definite, absolute and guaranteed further cost. There is no guarantee of anything else. Most normal programmers want to sit there and program what they're supposed to program and not something else. TDD can just as much damage structure as well as make things worse in the first run and if you use TDD as a ramp where's your ramp for the programming you have to do in writing tests? I've seen so many people like you completely unqualified spew out rubbish like you need statistical data. You can improve your attitude a lot if to consider that there are people out their that are unfathomably better than you. You do not take on a master swordsman by reading on your phone about the topic on the internet from people you reckon are master swordsmen (finding what you believe to be a better coach than your opponent). For TDD we don't apply it based on global measures. We apply it based on the given variables right in front of us relevant to the task given. We don't need to rely on external sources of authority, we are the authority. There are not reliable scientific studies on if TDD always guarantees benefits and there never will be because it simply does not. You do not even need to sample cases to deduce this. It's an a fact that it's a cost and nothing else is guaranteed. It's highly dependent on the situation. If you're only able to look at measures of situations over all (yes I have peer reviewed papers espousing the benefits of TDD and most of them fail including those cited on wikipedia). You can take a single real programmer, have them develop something good and proper well within their remit and they'll get on with it in their own way they know best coding it up front and will return with a decent level of structure, correctness, conciseness and all the other relevant properties. Add on the extra effort of TDD and it won't do anything. They're already at optimum. The only way you give them a benefit with TDD is if you also grant them to extra time (cost) that it takes. You may get a benefit but you are in fact giving them the benefit of more time not of TDD. In most shops I've seen this in there's a horrific tendency to cram everything in but not account for the additional time. This is one fault of programmers who often have an instinct to not want to say that will cost more. In a short exercise the cost of TDD may be contained but over the full life-time the costs can be cumulative and can multiply. It's very rare for naively applied TDD to ever hit a sweet spot. I can go into a situation, take everything into account and match TDD to it. If you have to judge TDD by overall measurements for the average situation you're giving away your inadequacy. You're unable to read a situation. You're acting on faith. You're gambling. Another poor instinct of developer is being too guarded about that something can go wrong or that it has gone wrong. If you're going to give TDD a go for a given situation that's one thing but if you're unable to admit that it can go wrong or that it has pack it in because your a project management technical disaster waiting to go catastrophically wrong. Things can go wrong with or without TDD. TDD can either be the thing that causes the failure or have no impact on the chances of failure. What kind of measurements do you even want? Correlation of causation. Sorry to break it to but what you're hoping for to try to reinforce your position is the former and that's not at all reliable. TDD is not necessary and it's dangerous if you're using it within limited budget but have no idea what you're doing. I can give you something statistically significant. Go out their and actually look at some code and projects. How many actually use TDD? What about the Linux OS? I can tell you people did not use TDD for most of that. They might certainly employ all kinds of testing and development strategies as they deem appropriate but they do not confine themselves to TDD. Principally development is talent driven. It's a skill. It's one you develop through practice. Whatever you think you get out of TDD you get out of just writing software especially as the code you're writing dependent on other code you've written is doing what TDD is doing in that respect. You're saying you need to program tests to work out structure, you can program to work out structure. Tests have a very bad habit of destroying structure because you're now rather than developing the structure your software needs that is appropriate to its operation you're developing for the tests needed for your cargo cult tests. It's rare when making software that tests reveal a structure that is useful. The same benefit can also be achieved writing tests after. By default it does not. In a brief window it may furnish a newbie with insight but that quickly wears off and early in the game anything they try involving programming will have that effect. The only prolonged and guaranteed path to the top is to program. That's what you're trying to master, that's what you've got to do. When you're doing it however you need to stay on track and program the thing you're actually programming. I would never hire someone to program TDD. What's the use of that? What company sells TDD as an end product? Try to sell it as much as you want. It's not a major selling point. I've never heard someone sitting their deliberating over whether or not to buy a particular phone interested in the software asking if it's TDD. There's also no code you can write with TDD that you cannot write without TDD. That's a fact. All possible code can be written straight up. TDD can offer you nothing you can't get without it. Another thing is that people who are not qualified at all think that TDD means testing. It does not. You can still have any kind of testing you want with TDD you're just not bound to devising the test beforehand. As I said, TDD does not add anything. It is a system of constraints. That's all it is. It takes away.
To Cu
To Cu Mês atrás
@ABC XYZ - Again, your latest discourse doesn't add anything more as to clarify how one concretely learn to write decent codes, to reach the state of 'being fluent' as in your words. You keep evading my question about your 'methodology', not intuition. There are two obvious flaws in your last argument. Firstly, TDD does not dictate that one must write test for everything just for the sake of testing itself, it actually aims to drive clean code design by suggesting testability of code as the guiding principle, with consequences to be observed such as simplicity, high cohesion, loose coupling, dependency injection, interface seggration, at the same time proposing some relevant good design practices. That's what I meant the cognitive structure underpinning the thought process of code design, which is obviously at a conceptual level not directly convertible into lines of code. Secondly, and more seriously, your analogy of the process of learning to code with how a child manages to walk and speak is plain wrong ! You likely know what gait means, and how an athlete could grow to win a 100 meter sprint contest, don't you ? All that are skills which need to be learned, trained, practiced, never intuition alone could do much in these faculties, period. So, should we be all right to have developers tottering through codes like those frail toddlers making their first walks, or would we be better off with those that are solid and competent in their jobs like the kind of professional athletes ? Yes, you did mention practice makes perfect, but not exactly how, by which concrete methods. Or just keep doing it until somehow good intuition getting formed, and what if that could take so long to happen, or never will ? To conclude, we may agree to disagree here, as long as there is still no factual evidence, i.e. statistically significant data, at least as I'm unable to give mine at the moment and you don't either, that could prove the advantages, or disadvantages of one over another paradigm, which is TDD vs your intuition driven approach.
ABC XYZ Mês atrás
@To Cu In practice, this kind of newbie friendly approach simply cannot yield the same benefits as being fluent. You don't seem to be getting the message either. Even for those of lower competence these things DO NOT WORK. Generally speaking that is. If you do a little of it then you might have a chance to receive a gain or failing that little is lost but otherwise the more you do it the probability of it not imposing a catastrophic grossly negative cost plummets to approach infinitesimally close to zero. The thing you're proposing to try to cater for low competence itself really doesn't work out without much the same competence to begin with. TDD doesn't do much to reduce iterations either nor train. TDD is not a clearly structures though process either. You still have the same unknowns up front. TDD really just dictates that you start your process writing tests. On a very small scale such as a minor CS assignment then it might not matter too much but real programming doesn't work like that and the overhead simply is not viable. You keep saying clearly structures thought process. There's no such thing in this case. If there were then it would be implemented in code and not reliant on the brain. It's a myth. Just saying it doesn't make it so. I will point out that virtually all programming is test driven but that's not quite the same as TDD which dictates certain things and really does nothing but remove options from the table. It doesn't add anything but rather removes your ability to approach programming in whichever way suits the situation. In coding practice makes perfect. You need some task, something to be driven toward. You do need to clearly defined what you actually want to achieve. Once you know that and roughly what the software should look like then you start to program it, however it works, whatever gets you there. An iterative process is not only not a problem but is a good thing. Once you've gotten it to work you'll learn along the way and figure somethings out. You'll also have questions like how or why that works that you answer. Once you do that then you're already better prepped and you will be able to intuitively go through and fix things up based on understanding. This process is predominantly natural like learning to walk or to speak. If you aren't able to do that, to learn, self improve and progress like that then you're probably going to struggle as a programmer. A bit or a larger problem with this is it can be relative. People can reach a point where it feel easy to them but then when sat next to a fluent person suddenly they see the other person makes it look easy compared to their performance.
To Cu
To Cu Mês atrás
@ABC XYZ - From your discourse, one could draw that, the degree of complexity of the task at hand is relative to the competency of the one who is going to carry it out, and no one could possibly get the code structure proper the first time, but would need to go back and forth several times to make it fit adequately. So, rather than making bet on some kind of intuitive manoeuvre, would it be much better to have a clearly structured solid thought process to guide newbies through the complex tasks of creating decent pieces of code, as well as help more advanced ones to reduce the number of round trips to restructure their initial creation ? What alternatives, other than previously mentioned intuition, would you suggest ?
ABC XYZ Mês atrás
@To Cu This shows a gap in your understanding. When someone actually learns to code properly that includes establishing structure. What you're talking about is something that becomes either largely intuitive, is only necessarily in special cases on demand or is already cater to by the code anyway (self revealing). You're position is from someone with lower innate ability. I can't juggle but some people can. In that case it's easy to see the difference but in software development it's not yet it does exist. For some people structure is intuitive already. A lot of people come in with the UML approach having learnt through study rather than practice and they fail to appreciate even things like that tend not to be particularly helpful for those with fluency and the knack. Something that is important to grasp is that real programmers don't get it all right first time around. They do restructure and reshape. However their initial structure and approach tends to be amenable to this and on average most things don't have structural problems. In TDD one way in which it might try to reveal design requirements is that it uses the library so you're getting an idea of what it has to look like on the outside but you get this when coding anyway. All the code you write is used by other code and this typically gives more than enough information for the developer. A real programmer might use a TDD based approach though not one doing it by the book but instead tailored for specific problems but they will actually be hard problems. What we see is starters who will find everything hard because they lack some combination of skill and experience then trying to apply TDD all the time, not even temporarily to learn the ropes. This doesn't make things easier for the junior at the expense of wasting the skill of the real programmer or even making it pointless to try to benefit from competence but it also quickly ends up holding back the starter as well. I've pointed out that you're never going to get the structure right first time and there's an ongoing among of churn here and there as a code base grows to accommodate more use cases. TDD is anathema to this as it means maintaining loads of tests that prevents refactoring. It also tends to damage code quality as it quite often ends up TDD creates use cases and concerns not in your actual software. I think it's also underappreciated that when you're strictly deriving tests first not only does that create tremendous cognitive load but some things can be harder to write tests for than it is to write and have it working perfectly in the first place. When a real programmer might be motivated to employ some TDD strategy it will be because the situation calls for it. They'll either have something that is unusually complex and ill defined or some kind of missing usage example such as if they are shipping parts out elsewhere. In rare cases it may be something else (in very rare cases it may be easy to create tests before hand).
CandidDate 2 meses atrás
an enemy of progress is a friend of history. A friend of progress is an enemy of history.
Standa Novák
Standa Novák 2 meses atrás
The whole talk sounds to me like "We don't have enough experience writing good tests and we are immensly reluctant to learn it, so we don't do it and tell everyone not to do it. We can write absloutely great production code, but our tests still suck after all those years." As a 5+years practitioner of TDD myself: - TDD discipline doesn't say that only unit tests should be used. Integration tests are needed too, as well as end-to-end tests, acceptance tests, contract tests and others. - TDD doesn't say that once you create a test, you have to keep it in the codebase forever. Some tests become redundant over time, so you just delete them or merge them together. Once the tests start to slow you down, the tests are not meeting their purpose and need to be redesigned. - Shipping code without tests is rude and prevents larger refactorings. If you ship a feature without tests and somebody breaks it by refactoring code you depend on in a way you don't expect, it's your fault that your feature doesn't work because you didn't provide a check that would prevent the guy to merge their changes. - "Can we just ship the code? We don't care if there is a few defects in production." Just don't tell the PM about tests. It is an implementation detail. If PM doesn't care about a few defects in production, then you are prototyping and trying to get to the market as fast as you can to know whether the feature is what people want. Then it's fine. But still - if you are implementing some new endpoint, you have to deploy the code somewhere to test it etc. So it slows you down, probably more than writing the tests. People don't want to write tests because it takes them a long time. But the more tests you write, the better you are and the faster you can create them. - "We wanted to modify some implementation detail and a lot of tests just and we had to fix them." That sounds like a poor class decomposition. Either mixing different things together or mixing different levels of abstraction together. - "Fitness tests are all red, because the implementation doesn't exist yet." Well you can write the tests up-front, comment them out, and uncomment them one-by-one once their implementation exists. Easy. - "Customers don't engage with the ATDD suite." Customers want bug-free software without regressions. If you can manage to have everything working without tests, go ahead, you don't need them at all. How about bumping a dependency version? How do you know that it still works? Would you manually test the whole system? - End-to-end tests are not enough. 1) They are slow (you have to load eg. selenium and it takes seconds to boot, so it is wasted time to run them after each changed line) and 2) They don't point to the exact spot where things go wrong. Therefore people are reluctant to refactoring and design experimentation, because something can break and it would be their fault. - "Developers hated check-in tests." So you don't mind having code that doesn't even compile in master? It wouldn't slow anyone down? - "People were pointing fingers who broke the test and who should fix it." What kind of productive work environment is that? - "Avoid testing implementation details, test behaviors" doesn't say "don't write unit tests, but only end-to-end tests". It says "Write unit tests where you test the input and output of the tested unit." ... Ah and the next part is about how it is done well and tests are cool, ok. As a long time fan of Uncle Bob and Kent Beck, I haven't learnt anything new here... PS: The sales nature of the guy is kinda disgusting. "You may not find this interesting, but I am going to put it on slides anyway, and we are hiring btw." "I am not going to sell you anything."
Standa Novák
Standa Novák Mês atrás
@James K You haven't read all of my comment then.
James K
James K Mês atrás
@Standa Novák The title says 'Where did it all go wrong?' - and you would understand that he is not calling it wrong if you had listened to the full talk, where he refers to the George Best story, and subsequently tells us to take the talk with that in mind, or words to that effect (i.e. its perceived to have gone wrong by those who think they are practising a TDD approach but actually aren't - at least not in the sense that it was originally intended.) Also your reply did have something more - an outpouring of emotion which seems to have driven your response - and also something less - namely about 8 years less experience of using TDD than Ian is drawing from.
Standa Novák
Standa Novák Mês atrás
@James K He shares his experience with "TDD is wrong" in the title, I share my counterpoint. Nothing more, nothing less.
James K
James K Mês atrás
He doesn't have a gun to your head. Stick to your way lol
blud work
blud work 2 meses atrás
The problem comes from tools that do "CODE COVERAGE". Because of that metric, devs just end up testing their implementation so the chart that goes to the bosses and regulators is "oh look 99% code coverage of tests" when in practice it's doing absolutely nothing to improve the code.
Charles Bodman
Charles Bodman 2 meses atrás
Blow your nose
Mark O'Neill
Mark O'Neill 2 meses atrás
Wow, claiming George Best as English? He was from Northern Ireland. Otherwise good talk.
S M 2 meses atrás
Jackson Galaxy?
Borys Mądrawski
Borys Mądrawski 2 meses atrás
It was about BDD and about how to not overkill ourselves with enforced TDD approach to have 100% coverage for every line of code in just a business code. Of course there is still a space for TDD if you develop/maintain a very technical code with a stable interface, like a framework (f.e. Spring), or some algorithms, when you really need to test every method and almost every possible combination of interactions and data.
Antryg Revok
Antryg Revok 2 meses atrás
Thank you for this, very very much: I had not been able to "get" TDD, until this. Salut, Namaste, & Kaizen! ( :
George Kettleborough
George Kettleborough 2 meses atrás
This is the most important thing I've seen this year. Wish I'd seen it earlier.
BlazingMagpie 2 meses atrás
I was stuck for months on this question about TDD: "How are you supposed to write the tests for the methods before you know how the structure will look like?". This answers it completely.
RiorXD 2 meses atrás
he talks code smells but all i hear is the sniffles. edit yea im gonna have to stop watching lol i made it 50 mins but him breathing in instead of just blowing his nose is killing me haha
Glen Rovid
Glen Rovid 2 meses atrás
His right about only 1 thing. Patterns should only be used in the refactoring step. ONE BIG PROBLEM WITH PATTERNS is the interface monsters you create. Lets say you have some giant patterns implemented using loads of interfaces and implementations of those interfaces. When you need to change the code that doesn't fit into your pattern monster like adding a single field into one of those functions you either end up rewriting all that code that is in the interface monster, or you end up hacking your beautiful pattern that turns your interface monster into an even uglier monster from BOB THE REAL SUPER STAR DEVELOPER
Glen Rovid
Glen Rovid 2 meses atrás
My question is. Who is testing the tests. More code = more maintance = more work = more bugs. Testing driven development is nonsense. If you write incorrect tests you write incorrect production code. Everytime you want to refactor production code you must refactor your tests. How often do you get bugs in an if statement or in a loop NEVER!!! All my bugs are intergration bugs, the database goes down, the API is not running. Only junior developers have bugs in their logic. I can write an entire application and build it and it compiles and works 100%. TDD is a waste of time MAN!!! Every company that uses TDD has half baked tests, and copy paste overwhere. People use those bloody mocks to give you false positives. OH ALL MY TESTS are green because my mocks have been setup. False mocking = false positives. You guys are smart people. Why push this test nonsense. OH TESTS give good documentation. NO Writing code properly then you dont need documentation. ONLY SHIT CODE = need documentation. I never use documentation. I am the bob guy, who gets hired to rewrite all and streamline applications. Whats the first thing I delete, the test projects!!! OH tests identify breaks in unrelated places, when you change your code. Lets get real. If you wrote your code properly the first time, it should be obvious what you broke immediately when you testing your application, and by that I mean normal testing not writing redundant code. Lets write code to check is method1 was called. Lets write tests to check if logger prints 'shit tests'. Unit tests just force you wrap code, to wrap code to wrap code to wrap code so you create so many wrappers around wrappers. This is good design?Come on!! Goal of good code is to have as little code as possible, little logic as possible, that is readible, easy to understand. Less code = good code FACT!!!! Less logic = good code FACT !! How can writing code to test code be a solution. That sounds like LIE! Now you have all these rules about how to right good tests. If you can write really good tests, then chances are you can write good production code. SHIT prodution code = shit test code. Common sense isnt common enough I get amongs these very smart developers. Now you ganna get developers who going to say test help with refactoring. I just use pen and paper, note the scenarious, and rewrite it. I don't need to spend hours writing mocks and setting up seams. PEN AND PAPER before code = GREAT CODE. IGNORE THIS CLASS - ITS NONSENSE FROM A REAL BOB SUPERSTAR DEVELOPER
Emad Ha
Emad Ha 2 meses atrás
This talk is just as annoying as the microphone
Shantanu Shekhar's June rft
Shantanu Shekhar's June rft 3 meses atrás
Basically automate the test that developers do manually anyways after implementation to verify correctness of the feature. That automated test is TDD.
Richard Hanney
Richard Hanney 3 meses atrás
Etc etc etc etc _sniff_ etc etc etc _sniff_ etc etc etc...
Richard Hanney
Richard Hanney 3 meses atrás
Stop zooming in. Just show what is on the screen behind him so it can be read and whats with the creaking leather sofa sound?
Shavais Zarathu
Shavais Zarathu 4 meses atrás
My brother once told me over the phone about a time when he went to pick up his car which had been in the shop for several days. Well, you can probably guess what I'm about to say - He paid the man, signed the papers, got his keys, went out to his car, sat down in it put the key in the ignition and turned it, and it wouldn't start. His car was "fixed".. but it wouldn't start. Those auto mechanics had sophisticated technology that they'd plugged into all the telemetry that the car was wired up to produce for them and their computer examined it all and told them that all the problems had been fixed, and the car was working fine. This didn't happen just once. They called him again. "Your car is ready. Sorry about that last time!" And for a SECOND TIME he went out to his car and it wouldn't start. THEY STILL HADN'T ACTUALLY TRIED STARTING THE F*ING CAR! It's hard to believe, but he claimed that it actually happened three times. Now are you going to say that this proves the need for more thorough automated tests? That would not be my conclusion. My conclusion would be that there is just really isn't any substitute for actually manually testing something with a human being. That would be my conclusion. Let's say I'm a writing game or UI or something. Well, I don't care, for example, whether or not some internal representation of a button showed up in some vector or in the results of some "public api call", I care whether or not the button actually showed up on the screen. And caused the right thing to happen when I clicked on it.I don't care if some pointer shows up with a non-null value, I care that the right sound plays when a user interaction that takes place should trigger it. I don't care if the mock up succeeded in transmitting to a test that some audible or visible thing happened correctly. I care about whether or not that audible or visible thing actually showed up at the time and in the way it was supposed to do. Let's say we're talking about an engine behind a game or an app UI. Something kind of on the "back end" of things that actually has a "public facing" api that doesn't have a direct UI. Well.. I don't actually care whether or not that engine works. I don't care if that back end api works, I care if the application works! I mean, obviously the back end has to work for the front end to work - but there a bunch of other things that have to work too for the front to work, so testing the engine in isolation from the application is kind of a pointless exercise. At least from a user's perspective. From a developer's perspective, it can maybe given them an idea of what's going wrong, I mean, debug logs can certainly help narrow where a problem is happening, for example. But as far as determining whether or not something is going wrong - the only trustworthy test is a manual human test from the front. If all your tests are green, are you really going to trust that that means your program is working and ship it without even starting up yourself and trying it out? Trying out all the stuff the automated tests are saying are working fine? If you're not going to ship it without doing that.. if you're going to do the manual testing anyway.. which you most certainly should... then what are those automated tests really for!? Why spend boogles of time creating and maintaining a bunch of automated tests that you're not going to trust anyway when you can just test the game or application as if you were a player or a user? Especially since that's a far better test anyway? When I test my game or my program, I find things wrong that I would never have thought of trying to test programmatically. I find things wrong that I can't think of a way to test for programmatically! I mean I might be able to, if I stretch my brain really hard, but it would take me forever. 1,000 times longer than it took me to just manually test it. So instead of spending all that time writing automated tests why not spend it fixing the problems found by manually testing? Especially since the vast majority of time, you're going to find a given problem once, and then never encounter it again. Unless you refactor. So let's say you refactor 2 or 3 times over the course of the development of something. Are you really going to write and maintain a big giant program that you will only ever really need run 2 or 3 times? And then you're not even going to really trust it's results anyway? It seems to me that automated testing might be worth it if you have a dedicated QA team and all they do is test the program. That team can can write and maintain the automated tests. Then the list of failing automated tests can be used to focus initial manual testing and bug-communication efforts, maybe. But I think developers should test by running the program like a player or a user and test the thing they just added or changed and anything else they can think of that might be related. Then when they think it's working they can pass it to QA testers who can spend all day every day trying to break it. But it seems to me that if neither team spends time creating and maintaining automated tests, and instead spends it doing manual tests and fixing problems, you'll probably get to the market sooner with a program that has fewer bugs and problems. Which is more common. Having a user report a problem with something you manually tested, or having a user report a problem with something you relied on automated tests to test?
Shavais Zarathu
Shavais Zarathu 3 meses atrás
@Mitchell So you're going to spend a year and million dollars to do something you can do in 2 minutes yourself for almost no cost at all? This is my point - the automated tests aren't worth their cost.
Mitchell 3 meses atrás
I must admit I didn't read your whole story... But your brother's mechanic doesn't need to do manual tests, they need to do integration / system tests. Just try start the engine with the key. Works? Done. Doesn't matter if a mechanic or a robot arm does it.
Jasper Schellingerhout
Jasper Schellingerhout 4 meses atrás
I believe it was UCSD Pascal that introduced the concept of unit (which I also believe was an inside the joke - Pascal is also a unit of pressure). A unit in Pascal was similar to the combination of the interface and implementation files separated as .h(pp) and .c(pp) files in C\C++. When referencing a unit you only had access to the interface section. It was essentially the "exports", the "interface", or the "header" section. You had no access to internals. The analogy with exports from Modules in Node.JS works very well, its pretty much a 1-1
Nawid N.
Nawid N. 4 meses atrás
I wish he didn't slur his words so much.
Andrii Andriichuk
Andrii Andriichuk 4 meses atrás
Nice talk, but too much repetition around black-box testing approach.
Ilya Denisov
Ilya Denisov 4 meses atrás
He described the problems with too granular tests that verifies small implementation details - they do exist and cause pain. Because ideas taken to the extreme are tend to cause problems. So the other extreme - having a single test per externally "observable behaviour" of the system - is painful too. And the speaker didn't seem to mention that (or am I missed it?). What about combinatorial explosion of execution paths? Having N simple if-s you have 2 ^ N execution paths - are you going to create matching amount of test cases for your behaviour? 256? 512? How far are you going to go on this way? The other aspect - test are not just to see if code works, they are also play role of the documentation with true examples. That is an important part too - it is not enough to describe a purpose of the class/method in the comment (or a name if it fits) - examples are valuable, especially for the edge cases. It is always a balance. You can't just run away from the thing that hurt you as far as you can - you'll got other problems there.
MrMartingale1 2 meses atrás
@Ilya Denisov didn't mean to sound categorical. I tend to be laconic in YT comments. I don't know much about UI development so perhaps you're right.
Ilya Denisov
Ilya Denisov 2 meses atrás
​@MrMartingale1 probably. But you also get it naturally when there a lot of special cases (typically happens in the UI). You may start splitting them in more classes but that will definitely kills readability due to inadequately high indirection/abstraction level - which also have a high cost that you have to compare with the costs of alternatives (e.g. complex/strict tests maintenance discussed in the talk). Why are you so categorical in your statement? What are your arguments? Please be more informative.
MrMartingale1 2 meses atrás
"What about combinatorial explosion of execution paths?" You get this problem when you don't stick to SRP.
Dave Parkinson
Dave Parkinson 4 meses atrás
This speaker is confusing Lean Startup from Eric Ries with Lean Software Development from Mary and Tom Poppendieck. He is talking about practices from Lean Startup but incorrectly calling them Lean Software Development.
Emil Huseynli
Emil Huseynli 4 meses atrás
True, in the end what one want to achieve is having only test cases which test behaviour and not implementation. And TDD is how it can be achieved. But testing implementation is not bad at all. Mocking is not bad too. Why? Because real world is full of legacy codebases created without testability in mind. And very often you just have to test implementation, you have to use mocking to be able to improve the design of that code. So, if you watch this video, double check that you understand that what this guy says is related specifically to TDD, not to unit/component testing in general.
coljackdripperofburp 4 meses atrás
TDD evangelists love moving the goal posts when confronted with reality. "Oh, it doesn't work for you because you did it WRONG! You should mock. You shouldn't mock. You should write tests first. You shouldn't write tests first. You should go for full code coverage. You shouldn't go for code coverage. You should test implementation details. You shouldn't test implementation details. You should write integration tests. You shouldn't write integration tests. etc etc."
Michael Stock
Michael Stock 5 meses atrás
Tdd makes coding quicker not slower Getting instant feedback from a test about your behaviour and defining that behaviour up front means you can track down issues much quicker than opening a debugger trawling through files looking for the break Why not both Test overall output and tdd to test units? It's no slower in my experience
Mohsen Maghferati
Mohsen Maghferati 5 meses atrás
Thanks for sharing this. So valuable stuff.
Alejandro Agua
Alejandro Agua 5 meses atrás
The best way is to be flexible. Like everything in life, there are tradeoffs. There's a tradeoff between the time it takes to ship your code and make your boss happy and to do TDD. You should know when it's good to apply TDD and when it's good to selectively tests only behaviors and high-level codes. Most of the time you want to strike the right balance between time to market and the time you spend on the TDD routine. But when being duct tape programmer is needed, high level over implementation detail, behavior over implementation, functionality over structure, public API over internal classes, write features or refactor over idly watching reds and greens.
johnkb79 5 meses atrás
Same presentation 4 years earlier, without creaks vimeo.com/68375232
Jim Deane
Jim Deane 5 meses atrás
Too late 🥺 I’ve “enjoyed” the sniffing and the creaks already. Great talk.. accidentally was doing it nearly right already.
We Do TDD 5 meses atrás
The tests are not for the customers to read. They're for developers to read, so that we can read the behavior of what we just wrote
We Do TDD 5 meses atrás
And this doesn't mean "Test everything through the UI with Cypress, Mount, etc." either. Be careful what Ian is saying to you here. He's not saying you must test everything through the UI (inverted test pyramid)
HELLO WORLD 5 meses atrás
Summary: Test the overall behavior (public API) not internal implementation details.
Mandar Mês atrás
@James Smith in case of a monolothic app that was already written without TDD in mind, you have to slowly convert its modules 1 at a time to testable, even then without coupling the test to the implementation details, only testing the public api i.e external interface methods of that module
James Smith
James Smith Mês atrás
@Mandar Yes but in a monolithic app the code is often messy / repeated and not modular
Mandar Mês atrás
@James Smith api does not mean the UI or http api, it means any part of your module that is used externally, i.e public methods but not the internal implementation this tests all the required behaviour and relevant code without breaking all the tests if the internal implementation is changed
James Smith
James Smith 2 meses atrás
@Tiit Kass The UI should 100% be tested, but not unit testing, browser/end to end tests.
Tiit Kass
Tiit Kass 2 meses atrás
@James Smith You may want to look at some Uncle Bob videos on this (ModelViewController). You do not want to include UI layer in testing web app if at all possible. As Ian pointed to in his talk as well in this video, UI can change without the underlying behavior changing.
Fazli Zekiqi
Fazli Zekiqi 5 meses atrás
Great lecture! Explanation about the "duck tape programmer" was funny!
ZheToralf 5 meses atrás
Claudio Lassala
Claudio Lassala 5 meses atrás
Folks who enjoyed this talk might find something in my posts on testing: lassala.net/category/testing/
Simon VV
Simon VV 6 meses atrás
Notes I made during this presentation (just a dump, might be useful to some): - Test requirements, not low level - Test public API. Given when then - Test the exports from a module - Focus on higher-level - Test modules, not class - Refactoring is needed to see what is implementation and what is exports from module - Test behaviours - Think about your code as an api - Test the abstraction, not the implementation - Test are isolated and with shared fixture (to run quickly) - Red-green-refactor (go fast to working code) - No new tests during refactoring - Heavy coupling is the problem with all software - Thin public api - Refactoring = changing internals - Patterns in the refactoring - If you're not really sure, write tests for implementation (delete the tests) - Not classes, behaviours - Don't isolate classes in testing - Private methods (these are implementation details)
Edd Mês atrás
Great talk by Sandi Metz that pretty much echoes those great notes- it’s Ruby based but I got some good value from it: brshow.info/watch/URSWYvyc42M/video.html
Cryp!0G00n Mês atrás
timestamps would be nice but thank you for putting this together
Dan Haiduc
Dan Haiduc 2 meses atrás
@Tiit Kass You are absolutely right. After watching Fast Test, Slow Test I have realized that the whole test suite should run in **less than two seconds**. It is possible if you don't invoke any big frameworks during the tests: brshow.info/watch/RAxiiRPHS9k/video.html
Tiit Kass
Tiit Kass 2 meses atrás
@Dan Haiduc Clarification: whole test suite should run in under a few minutes, not just one unit test. And having DB communication during testing is OK as long as it is isolated from other tests (by either cleaning it or using exclusive instances or what ever. Basically memory based db that is recreated for each test).
Dan Haiduc
Dan Haiduc 2 meses atrás
Also, keep tests fast (
Magne Matre Gåsland
Magne Matre Gåsland 6 meses atrás
35:20 "The unit of isolation is the test. A lot of mistakes has been made, because people think that the unit of isolation is the class under test. It is not." I think we can blame the name "Unit testing", for that. Because it should have been named "Isolated testing", "Compartmentalized testing" or simply "Testing", since it simply stipulates a good testing practise. Rather than seemingly referring something specific which is to be tested, the fabled "Unit". See: en.wikipedia.org/wiki/Reification_(fallacy) Well, I guess naming is a hard problem, but this one should have been more thought through from the start, considering all the misdirection and wasteful efforts it has created throughout the years with spades of programmers getting the wrong idea from the start, and being led down the wrong path with various unit testing frameworks. "There are only two hard things in Computer Science: cache invalidation and naming things." - Phil Karlton
Magne Matre Gåsland
Magne Matre Gåsland 6 meses atrás
How does TDD solve the case of "I know what I want when I see it"? Oftentimes you don't know what you want until you get to see your data output, and are able to see and manipulate it into the shape you'd like (especially with complex ordering and/or filtering of potentially large datasets).
Magne Matre Gåsland
Magne Matre Gåsland 6 meses atrás
" *Kent Beck* > I have no business programming something before I know how to test it. *DHH* > I don't know how/what to test before I've seen the program. So DHH tries something and see if he likes it or not. If he doesn't like it he throws the code away. So any tests written prior to the code would've slowed him down (given that any 3rd party code he uses is well tested and almost bug free) " Sourced from Richard Metzler's comment at: brshow.info/watch/z9quxZsLcfo/video.html
Magne Matre Gåsland
Magne Matre Gåsland 6 meses atrás
Uncle Bob (Robert C Martin) weighs in on When TDD does not work (talking about why we don't write tests for CSS): "Besides, how do you know if the CSS is correct? Remember we are doing TDD. We are writing our tests first. How do you know, in advance, what the CSS should be? The answer is that usually you don’t. Usually you write some initial CSS, and then you look at the screen and fiddle with the CSS until it looks right. Your eyes, and your mind, are the actual test. Once the CSS is right, there’s no point in writing a test for it. So near the physical boundary of the system there is a layer that requires fiddling. It is useless to try to write tests first (or tests at all) for this layer. The only way to get it right is to use human interaction; and once it’s right there’s no point in writing a test." blog.cleancoder.com/uncle-bob/2014/04/30/When-tdd-does-not-work.html What if most programming (especially of new/innovative systems) are like this? To use his words regarding CSS, but applying them more generally: Usually you write some X, and then you look at the screen and fiddle with X until it looks right. How do you know, in advance, what X should be? You could potentially do everything with TDD, because to write some code, you have to have _some_ intention. But why waste time and effort in writing tests for intermediate data that just serves the purpose of giving you an output to fiddle with until you know what you really want? "Anything that requires human interaction and fiddling to get correct is not in the domain of TDD, and doesn’t require automated tests." - Uncle Bob
Programming Made EZ
Programming Made EZ 7 meses atrás
I do appreciate his attempt to talk about the problems he's experienced but honestly, this talk should be renamed "How to Blame TDD for People Who Don't Understand TDD". :/ I'm 14 minutes in and I've already got a list of 10 things he's got completely wrong. 7:12 - They are arguing that you should be less professional. Can't a doctor just go in and do the surgery? They don't NEED to sterilize everything. 8:04 - Compared to what? After 10 sprints how many bugs would you be fixing compared to new feature releases? 8:16 - That's a failure to adhere to SRP and OCP, not a failing of TDD. 9:21 - No, that's what the SOLID principles promise, which it appears you aren't doing. 9:40 - That's EXACTLY what Tests are for, to be an obstacle so you make sure you aren't breaking things. 9:50 - Again, if you are trying to CHANGE the implementation code you're doing OCP wrong. You should be EXTENDING and REPLACING not changing. 11:35 - That's not an argument against TDD, that's an argument against testing period. 12:05 - Bob probably worked for Volkswagon. 13:21 - Once again trying to change something instead of extend or replace. Also, bad naming practices isn't an excuse to stop testing. 13:59 - Sounds like people aren't doing the "refactor" part of TDD. We get it, TDD makes you accountable for your code and people don't like that.
Dan Foulkes
Dan Foulkes 7 meses atrás
dude who does your sound control? every video I see you do I'm always distracted by the gut wrenching sounds that are always in your videos. For example the gulping of water, the sound of microphone grubbing against a rough surface. It's very distracting. to quote the Smiths "hang the DJ"
Dan Foulkes
Dan Foulkes 7 meses atrás
Forgot to add. Great content
DIMPU KUMAR 7 meses atrás
Very informative. Thanks for posting!!
Adam Millerchip
Adam Millerchip 8 meses atrás
The references mentioned in this talk: Refactoring, by Martin Fowler Test-Driven Development: By Example, by Kent Beck Introducing BDD by Dan North (website, not a book: dannorth.net/introducing-bdd/)
Cheng Fei
Cheng Fei 8 meses atrás
This sounds like BDD (Behavior driven development). But BDD tests usually will take minutes since it covers many sub features whereas unit tests only focus on a single feature.
Zhuinden 7 meses atrás
Can't you run behavior tests for a given subfeature, like a unit test suite?
Austin T
Austin T 9 meses atrás
Will the creaking ever stop! This is such a good talk and it is ruined by it.
Ronny Bubke
Ronny Bubke 9 meses atrás
Great Talk. Use it to convince people to do it right.
Peter Mortensen
Peter Mortensen 5 meses atrás
Except for audio problems. How did you manage? 5 minutes per day?
nyrtzl 9 meses atrás
If I can't understand the test then I guess the comments are bad and it isn't linked to an item in either a design or requirements documents. But writing down that stuff slows one down too. Then again if it's not written down and it ever becomes necessary to rewrite for example an entire application then you're screwed because there's no easy to grab previously done work that you can easily reuse. That's what TDD ultimately aims at, right? That is, to help you do your work in a way which makes it easy to reuse and build upon in the future without forcing you to backtrack. TDD is just a tool which if applied appropriately at the right spots should help you keep your velocity up better in the long term. Unless you invest in quality now, you will have less of it in the future and that stuff adds up. Do you want to be in a positive or a negative cycle or spiral?
Mar. M.
Mar. M. 10 meses atrás
That talk fixes all my problems I had with TDD... Have to read the originals... TY
coljackdripperofburp 10 meses atrás
Some super contradictory advice here: So ATTD doesn't work. 10 minutes later: Don't write tests against concrete methods, write tests against requirements! Seriously, TDD people are a cult. 'Oh, it isn't working for you? You must be doing it WRONG! Read the holy book again and try harder'.
Fifamobile Code
Fifamobile Code 11 meses atrás
From reddit
Peter Mortensen
Peter Mortensen 9 meses atrás
Do you have a reference?
Mykyta Fastovets
Mykyta Fastovets 11 meses atrás
Incredibly useful, especially when thinking through how to implement TDD correctly after starting lean, but your product starts reaching enterprise level
i velinov
i velinov 11 meses atrás
Do exactly opposite what this guys saying to benefit from TDD. If somebody says dont test implementation details ironically he is a duck tape programmer. Test always in isolation, mocking is a great way to do it. Prove every line of your code is necessary. Always test edge cases. Use a mutation testing tool. Behavior testing in good but it is about integration testing not TDD.
Michael Stock
Michael Stock 5 meses atrás
@coljackdripperofburp tdd makes you code quicker not slower You get instant feedback on a small unit so you know what goes wrong and where
coljackdripperofburp 10 meses atrás
if your client is happy to pay you for wasting your time, sure
Geshtu 11 meses atrás
I clearly hold a minority opinion, but it still seems to me that TDD (and all ideologies like it) comes from a magical place where business/user requirements are clear and determined in advance and never change, and developers somehow not only know in advance how they will develop a thing and what challenges they will face, they also somehow know the best way to do it, such that their design / API will not change. After coding for over 20 years and working many years in automated test, I have yet to meet such a developer. Coding involves exploration. You can't test for what you haven't yet discovered, and only a fool pretends there is nothing to discover. My disagreement with TDD is not because I think it is slower. It is because I just don't think developers (or anyone for that matter) are good at predicting the future. I suspect what ends up happening is that tests get updated after the software is done, which is fine but it's not what we're being sold. I have not written (m)any pieces of software where I knew the correct design or even how it would eventually work, before I started. I have a rough idea, but you can't write tests for a rough idea and expect nothing to change. Invariably the process of writing software involves some measure of exploration of the problem space and some iteration over various interfaces and designs, before eventually the API or UI or design begins to take shape and stabilise. Often the first attempt is not the best one, and yet you need to make that first attempt in order to better understand the problem space, and by then you will have gained the knowledge required to implement a more robust solution. Sometimes this process repeats several times. This solution may well (and indeed often does) change the contract with its would-be consumers (but that's ok because they haven't been finalised yet either). It seems to me that if you write the tests first, your lack of knowledge/foresight of the final product will be reflected in the tests, and they will then constrain the implementation unnecessarily, as you inevitably implement the code to conform to the tests rather than to solve the problem you originally intended to. Is it really so bad to write software, or even just a component, and THEN write the tests now that you better understand how all the pieces fit together? You write the code, and iterate until the design feels right. The interface is also perfected here. Then having understood the thing to be tested, you (or better, someone else who understands the thing to be tested, or better still, both) write the tests that are designed to (a) validate the contract between software and consumer and (b) try to break that contract. Apologies for long rant but I assume someone will correct me and I will learn something new.
Elderly Nerd
Elderly Nerd 4 meses atrás
Can I buy you a beer? I can't agree enough. If you do TDD for most projects you will spend your entire time and budget before you have even delivered a prototype to a very unhappy customer.
Raúl Vázquez
Raúl Vázquez 4 meses atrás
@Petr Gladkikh the result is what matters, of course. Some people feel safer doing small steps and constantly verifying they are on the right path.
Petr Gladkikh
Petr Gladkikh 4 meses atrás
@Raúl Vázquez Also I have question about word "quickly". Why? I think here is the core of disagreement, I think that people who like TDD - are the ones who _feel_ productive doing it. You create problems, you solve problems, all that brownian motion. While if you sit there thinking you are not typing anything - that arguably may not feel like a productive activity. But it is the result that matters.
Petr Gladkikh
Petr Gladkikh 4 meses atrás
@Raúl Vázquez good design fullfills requirements, there's no contradiction. And it is not optional, while unit tests restrict how you can (or willing to) change your system. I still fail to see why should I bang my head against every wall in the room (tests red), make random turns (bad implementation), and only then walk our of room suddenly realising where door is (gainining understanding). I prefer to look around, to see where the door is. Then write a test to cover that - the test would be a lot simpler then. Still no answer why I should write tests BEFORE the code. Also I think TDD is a misnomer. It is actually a Unit Test Driven Development, by the way.
Raúl Vázquez
Raúl Vázquez 7 meses atrás
> comes from a magical place where business/user requirements are clear and determined in advance and never change It takes several iterations to get the requirements right, and on each iteration, they will change. Looking at the latter part of your comment, I think you agree on this. > Coding involves exploration That's the key, where TDD helps is on exploring the unit (as a use case, not a class) instead of the entire system. > You write the code, and iterate until the design feels right. [...] having understood the thing to be tested, you (or better, someone else who understands the thing to be tested, or better still, both) write the tests that are designed to (a) validate the contract between software and consumer and (b) try to break that contract. Yeah, that's it. The difference with test-first TDD is and the iteration is done. Instead of favoring the iterations on design, it favors the iterations on getting the requirements right. Around 40:20 Ian goes deeper into the Red Green Refactor cycle. First, the requirements (with tests) are a bare definition, something that doesn't work (red), some code is written and to make the test work, at this point the code is DIRTY and SINFUL, there IS NOT good design, but this initial design and this initial definition can provide feedback quickly, it can be validated and with more details come a better understanding (even validate them with someone else as you said), a few iterations might be needed to get to an acceptable behavior (green) the important thing is to not forget the exploration, to no forget the discoveries, the new details of the requirements, and the way TDD does it, is writing them in the test, once there, the design can be improved (refactor), so the design can be changed without changing the requirements (already validated by tests at this point). With this approach, the requirements details (and their validation, with test) come before the design. The logic behind it, is: What's more important? The system behavior fulfilling the requirements or the design behind it? In TDD, a change in a test should come from a change in the requirements (the contract), a change in the design (refactor) should not affect the test, in practice, this is hard to get, but knowing it, changes at what level the tests are written and lowers the coupling.
Research and Build
Research and Build 11 meses atrás
43:48 huh great point. I always get stuck on the analysis paralysis portion these days. I think i need to get Kents book
Peter Mortensen
Peter Mortensen 9 meses atrás
Kent who? Kent Beck? www DOT youtube DOT com/watch?v=cGuTmOUdFbo
Abdul Hanan
Abdul Hanan Anos atrás
Its always goes straight in the box of understanding when someone talk about actual philosophy of subject. He is talking with experience. Real Gold!!! THANX :-)
Chemaclass Anos atrás
TDD is a tool. You should first learn how and when does makes sense to use it.
Channel Dad Bryon Lape
Channel Dad Bryon Lape Anos atrás
My current project uses SpecFlow for mid-level integration tests. It really sucks. More code is written for them than the actual implementation and are very fragile.
Lazar Otasevic
Lazar Otasevic Anos atrás
mocks are nonsense
Peter Mortensen
Peter Mortensen 9 meses atrás
Why are they nonsense?
krumbergify Anos atrás
I have a love/hate relationship with ”Bobs” ;)
Peter Mortensen
Peter Mortensen 9 meses atrás
Office Space reference? E.g. _"We fixed the glitch."_ www DOT youtube DOT com/watch?v=NnJzct7h3Dk
Camilo Uribe
Camilo Uribe Anos atrás
24:15 Adding a new class is not the trigger for writing tests.
Camilo Uribe
Camilo Uribe Anos atrás
Is TDD Dead? martinfowler.com/articles/is-tdd-dead/
eltreum1 Anos atrás
A refreshing voice of reason. I do not consider myself a software engineer or a programmer but I develop and write code mostly for the domain I am an expert in, network engineering and automation. I adopted a testing philosophy kind of how the speaker describes so I did not hate the process of developing. My tests were usually small to simply verify the module produces the expected results reliably and was fault aware/tolerant so there were no crashes or poising of a chain of outside events. In the networking world certain random failures are expected and have to be handled as a part of any basic operation and telcos are micro service happy. You can destroy a lot of network routers quickly with badly behaved code. To me its a matter of using the right tool for the right job and tests are simply tools to either validate intended operation, hunt obscure bugs, or aid in optimization. Like the speaker said I can change 'how' I got from point A to Z in the module and it never breaks my module level tests. Integration testing and system wide tests are their own animals that should work much the same way. Validate intended operations first and use extra deep level tests only when really needed to work out unforeseen issues when they arise and get rid of them when the issue is resolved. The only time I am testing implementation is isolating some unusually weird bug or A/B benchmark testing different ways to do the same task to optimize performance. Once my concerns are addressed those tests get removed. The other good use of deep implementation testing is when security vulnerability profiling is concerned or you have to satisfy unique tests like FDA tests for medical devices. Those are domain specific edge cases that should not dictate process over every other domain. Use the right tool for the right job at the right time. I think concepts like TDD were made to help foster good testing disciplines in lieu of real world experience as a safety net. These philosophies kind of get treated like a silver bullet or a magic-black-box module/lib you sometimes may use or even a religion. You don't know how it entirely works you just believe it always does. If you do everything exactly the way it says to, no matter how crazy it seems at the time, everything will work out fine. Whaaaa noooo....
Kc songtv
Kc songtv Anos atrás
great talk and well educative.thanks alot for this wonderful video
Vedran Mandić
Vedran Mandić Anos atrás
Amazing lecture. Appreciate the hard-experience led talk and that is what gives it immense value, not the TDD/BDD but the higher understanding WHAT should be tested, i.e. the user behaviour. Fantastic, thank you.
bicunisa Anos atrás
Who the heck is playing with a balloon in front of the mic?
Colin Mês atrás
I didn't hear it until I read this comment 30 minutes on lol... NGL I don't know if I can finish it now
volker engels
volker engels 3 meses atrás
His shoes - I guess!
Jay Ar
Jay Ar 10 meses atrás
bicunisa 😂😂 that weird indd
Silviu C
Silviu C Anos atrás
24:40 that sniff
Colin Mês atrás
Mi Bi
Mi Bi Anos atrás
This guy is my definition of a hipster.
David Julitz
David Julitz Anos atrás
Easy and clear.
Dairy Pusher
Dairy Pusher Anos atrás
maybe a second microphone, and an enemy of the speaker is constantly rubbing his thumb across it.
70ME3E Anos atrás
this is gold. THIS is how testing makes sense.
MrFedX Anos atrás
I’ve had a hard time getting inte TDD and now I realize why. Great talk giving the philosophy and practice of TDD. I’ll read Kent Becks book right away and start testing behaviour. :)
Jamal Rahhali
Jamal Rahhali Anos atrás
It's too bad he was running out of time at 57:00. I would have loved to hear more elaboration on the testing that should be done with the adapters in the Ports and Adapters model. Sure, I can test my application through my ports, but how do I know that my adapters and ports communicate correctly? How do I know, for example, that my HTTP adapter returns a 404 when my core applications throws a UserNotFoundException? Surely, I don't duplicate all my ports tests, but calling them through the adapter interface. It would have been nice to hear a little more about that part.
Rafael Silva
Rafael Silva Anos atrás
Hard to me (non native speaker) to understand whats being said, difficult accent e disturbing background sounds. I prefer a more straight to the point approach, you come and go too much on the line of thinking. Nonetheless good content. I will watch it again to absorb your expertise, maybe with earphones.
Channel Dad Bryon Lape
Channel Dad Bryon Lape Anos atrás
Nice presentation, but the rubbing noise is very annoying.
Dingo Egret
Dingo Egret Anos atrás
If your tests are brittle, that means your program is brittle. Trust me, this is a common pitfall. For example, I have a TimeWatcher object with a bunch of tests. The TimeWatcher uses Utc to compare timestamps and does some stuff. My tests reflect this. Later I decide, oh no, I need to use my Local Time. You make the change, and your tests break. This is proof that your program is brittle. What you should have done was construct the TimeWatcher with an object that abstracts away dealing with variations of time. That way, you simply add a new LocalTime object, test it with new tests, and inject it into TimeWatcher. None of your tests break. Your code needs to be open for extension, but closed for modification. If it's not, your tests will let you know.
Channel Dad Bryon Lape
Channel Dad Bryon Lape Anos atrás
It went wrong at the same point as everything else, when the professionals got ahold of it and wrote books on the subject, without ever actually doing it.
D 27 dias atrás
Ali Naqvi
Ali Naqvi Anos atrás
This guy is speaking from hard earn't real-world experience. We need more engineers like him imparting their knowledge. Rather than 25 year olds who have real industry experience of 1.7 years and have already written 2 books.
Wiz 2 meses atrás
@626Pilot Uncle Bob is a lot more interested in selling you his consulting & books than telling you things that are true.
Mandar 2 meses atrás
" earn't "
Jon 5 meses atrás
@tamashumi that's not a problem with comments, that a symptom of sloppy programming, if the code was changed so that it invalidates the comment, chances are it also breaks something else, if the developer fails to even update the comment you can bet that he also failed to consider collateral that could occur do his change. That's not to say that all code should be documented, just that is not a compelling reason not to.
Sufian Babri
Sufian Babri 5 meses atrás
@tamashumi Uncle Bob is not against comments but those which are unnecessary. Some people love to comment because they know that their code is crap. Uncle Bob says, "A comment is a failure to express yourself in code. If you fail, then write a comment; but try not to fail.".
Zhuinden 7 meses atrás
@626Pilot He's saying you should test 100% of your coverage, through behavioral tests. If you have code that never runs, why have it, right?
Steve Carter
Steve Carter Anos atrás
35:11 I've spent nearly a decade thinking I was the only one who spotted that
steve hoff
steve hoff Anos atrás
Theoretically I understand what the speaker is talking about however in practice I couldn't disagree more than with his ideas. Having done tdd myself since about 2005 I found that the key to successful test implementation and maintainable tests is making sure that your code follows Uncle Bob's principles single responsibility being probably the greatest or most important I should say. If your objects do one thing and do only one thing well or only have one reason to change then you're testing becomes quite simple. I understand that this is not how the real world works most of the time however that is what we should be striving for as software Developers.
Peter Mortensen
Peter Mortensen 9 meses atrás
@ishcatu ( _shoud_ → _should_ ) (Also, you can post links - just encode them somehow to prevent automatic removal. I have an encoder (paste into the text area and press _"Transform for BRshow comments"_ at: _pmortensen DOT eu/world/Text DOT php_ )
ishcatu Anos atrás
Uncle Bob stated in his book "Clean Architecture", that the single responsibility principle is the most misunderstood one. It is absolutely not about an object doing "one thing". Doing one thing is about cohesion and not about the SRP. A method should do one thing and an object has maximal cohesion, if every method of the object uses every member variable. Sometimes it's okay to be pragmatic and to allow compromises with the level of cohesion. The SRP though is about being responsible towards one user/code group (the users of the code can also be other code) and an object can be really small and cohesive and still violate that principle, if its users/code disagree on its features and want different changes, because there shoud be only *one reason to change* (that's meant literally) and that reason should be the one and only user/code group. Even a stupid very little data container without any methods can violate the SRP, if it is potentially being used by non-agreeing user/code groups. And Uncle Bob has the same view on TDD as propagated in this talk. This can be read on his cleancoder article about test contra-variance. Just google: cleancoder test contra-variance.
ishcatu Anos atrás
@626Pilot You can test at the "ports" of modules and still cover 100% of code lines (except I/O which gets replaced in tests), because all the internal classes (that were created in the refactoring step) are used. Of course there are a lot more combinations at the ports and the organization of tests gets more difficult.
626Pilot Anos atrás
I have done it the way this guy says (only test behaviors) and I have done it the way Uncle Bob says (every line and branch, 100%.) The Uncle Bob way is hard to get into, initially. It seems tedious to get to 100%. But once I was doing it for a few weeks, it was no longer tedious. It became second nature. Now, my code doesn't have so many hiding places for bugs and design problems, and it's so much easier to understand and maintain. I will never go back to this behavioral testing nonsense. It would only make my job harder and more stressful. 100% coverage is the only sane stopping point. Uncle Bob wins, just like always.
MBlu3 Anos atrás
there's a lot of awkward creaking and sniffing in this video
steve hoff
steve hoff Anos atrás
Coke sniffles?
carlmango11 Anos atrás
George Best is not English.
🚀 DevTernity 2019: Kevlin Henney - Lean Code
Visualizações 26 mil
Visualizações 6 mi
Sthefane Matos
Visualizações 637 mil
BTS: Dynamite
The Late Late Show with James Corden
Visualizações 4 mi
Extreme Programming 20 years later by Kent Beck
Visualizações 46 mil
Jim Coplien and Bob Martin Debate TDD
Visualizações 117 mil
How To Speak by Patrick Winston
MIT OpenCourseWare
Visualizações 2,7 mi
The Art of Code - Dylan Beattie
NDC Conferences
Visualizações 1 mi
Effective Unit Testing by Eliotte Rusty Harold
"Uncle" Bob Martin - "The Future of Programming"
Paul Stringer's Mobile Tech
Visualizações 1,5 mi
TDD for those who don't need it - GopherCon SG 2017
Singapore Gophers
Visualizações 29 mil
Visualizações 6 mi
Sthefane Matos
Visualizações 637 mil
BTS: Dynamite
The Late Late Show with James Corden
Visualizações 4 mi
Eu você e nós
Visualizações 578 mil
Universo dos Oráculos - Samara Tarot
Visualizações 57 mil
Vanessa Lino
Visualizações 64 mil
Live em recuperação | LEDA NAGLE
Leda Nagle
Visualizações 78 mil
CHÁ REVELAÇÃO *menina ou menino?
Taciele Alcolea
Visualizações 1,9 mi