Agile Software Development
Agile Software Development
  • 11
  • 14 498

Відео

Robert Cecil Martin (uncle Bob) demonstrates test driven development by implementing a stack in Java
Переглядів 13 тис.Рік тому
Robert Cecil Martin (uncle Bob) demonstrates test driven development by implementing a stack in Java
Robert Cecil Martin (uncle Bob): thou shall not mandate comments
Переглядів 34Рік тому
Robert Cecil Martin (uncle Bob): thou shall not mandate comments
Robert Cecil Martin (uncle Bob): do not check in todo comments
Переглядів 114Рік тому
Robert Cecil Martin (uncle Bob): do not check in todo comments
Robert Cecil Martin (uncle Bob): let test driven development drive design
Переглядів 532Рік тому
Robert Cecil Martin (uncle Bob): let test driven development drive design
Robert Cecil Martin (uncle Bob): thou shall not be good at hot keys for debugging
Переглядів 27Рік тому
Robert Cecil Martin (uncle Bob): thou shall not be good at hot keys for debugging
Robert Cecil Martin (uncle Bob): how to test legacy code
Переглядів 165Рік тому
Robert Cecil Martin (uncle Bob): how to test legacy code
Robert Cecil Martin (uncle Bob): love and hate software engineering industry
Переглядів 57Рік тому
it is hard to compound knowledge as software engineer because it will always about following the next paradigm, concept, programming language
Robert Cecil Martin (uncle Bob) expects all tests to be automated
Переглядів 43Рік тому
Robert Cecil Martin (uncle Bob) expects all tests to be automated
Robert Cecil Martin (uncle Bob) expects fearless competence, constant refactoring with TDD
Переглядів 188Рік тому
Robert Cecil Martin (uncle Bob) expects fearless competence, constant refactoring with TDD
Robert Cecil Martin (uncle Bob) expects stable productivity
Переглядів 78Рік тому
Robert Cecil Martin (uncle Bob) expects stable productivity

КОМЕНТАРІ

  • @whymydiy
    @whymydiy Місяць тому

    This exercise looks a lot how AI tries to write code for me 😂

  • @GRHmedia
    @GRHmedia 5 місяців тому

    Rewarding at work. Spend 3 to 4 times the amount of time to produce the same thing. Produce 2 to 3 times the code that has to be maintained. Your companies cost increased and the amount of time to produce the same product increases. Yet, the cost of running the business and hourly wages, electricity, property cost and so on all stay the same. Sure do this if you like the unemployment line being in your future or your company going bankrupt.

    • @tb15900
      @tb15900 3 місяці тому

      When you’re regularly using TDD it doesn’t take 3/4 times as long. Also you don’t need to maintain your tests, if your tests need maintaining then your tests are bad tests. You only ever test the public interface, which shouldn’t change regularly.

    • @VictorMartinez-zf6dt
      @VictorMartinez-zf6dt 3 місяці тому

      It's plainly clear that you have never been part of a quality software operation and I would never want to touch or be affected by the programs you're responsible for.

  • @Guillermo88077
    @Guillermo88077 5 місяців тому

    Amazing!

  • @GRHmedia
    @GRHmedia 6 місяців тому

    I hate TDD if anyone who I hire ever suggest it it will be their last day at work for me. It serves no good purpose in my opinion. You create code to test other code but you don't create code to test the code that is testing the other code. That is like using a un-calibrated power meter to test and calibrate another meter. It is just stupid! I've seen people screw up the test code. In fact there are youtube videos showing people do that. But lets say you want to modify the way something works so then you have right more test code just to update that function or class or first. I've never once seen the best code result come from TDD. It instead encourages people to look at only small issues rather than look at the larger picture in solving something. So rather than end up with some efficient code you end up with many if else nest piles of crap for code that people wrote because they make these incremental changes to comply with the TDD testing changes. By the time they get to the point were they have something working they don't want to go through and do the work of refactoring the primary work to improve it and choose to just leave it as is. You end up with 3 to 10 times the code written just to get the same project done. You wonder why your over budget and costs are going through the roof. The only programmers i know who love this crap are amateurs and people getting paid by the line or hour in code.

    • @Dalendrion
      @Dalendrion 6 місяців тому

      _"but you don't create code to test the code that is testing the other code"_ In this video, Bob did that by first making the test fail, and then making it pass. It's true that that only tests the test in that moment. It's not a test regression test. (Whoo, complicated names here! xD) But it's better than writing tests after the fact, that have only ever succeeded. TDD or no TDD, tests testing tests is not something that comes naturally either way. In both cases you have to put in the same effort to accomplish that, or you accept not testing tests. This does not affect your choice whether to use TDD or not. _"I've seen people screw up the test code."_ I wonder if these people have applied TDD in the optimal way. Not that there's ever a guarantee for correct test code. That's not the case ever. This does not affect your choice whether to use TDD or not. _"It instead encourages people to look at only small issues rather than look at the larger picture in solving something."_ I think that is what you want! At the moment, you're writing a unit. Focus on the unit. Make sure that that does what you want it to do. Once finished, you take a step back, and look at the picture one step above the unit: the module. You can apply TDD to the module also. Once the module does what you want it to do, take a step back, and look at the picture above that: the program. And, you guessed it, you can apply TDD to the program also! Losing sight of the bigger picture is not a TDD problem. Because you can apply TDD on all levels. (Or BDD if that is your jam.) _" rather than end up with some efficient code you end up with many if else nest piles of crap for code that people wrote because they make these incremental changes to comply with the TDD testing changes"_ Now this is an actual concern. One that I don't know the answer to. I would say that this should be thought about during the refactor steps after each increment of the TDD process. Make the test fail, write code to make it pass, refactor. When people refactor, they should engage with the larger picture at least a little bit. I can imagine that this takes experience to pull off well. You also voice concerns over time and costs. And I understand why. Programming with TDD takes time. Especially if programmers aren't already quite experienced with TDD. The hope is, and the promise is, that TDD helps you win that time back by preventing bugs and making them easier to solve. It's hard to sell, because you don't normally see this trade-off. You don't see the time you don't spend. You only see that TDD takes more time during development. I won't say that TDD will make true on its promise. That is up to the developer. Hopefully other people will share their thoughts, because I find this an interesting topic. It's fascinating to see the different pros and cons of TDD, or any methodology.

    • @bladekiller2766
      @bladekiller2766 Місяць тому

      Tell me you don't know anything about unit testing and TDD, without telling me you know nothing about unit testing and TDD

    • @TheRafark
      @TheRafark 28 днів тому

      “ The only programmers i know who love this crap are amateurs” Every accusation is a confession

    • @renegadosPL
      @renegadosPL 22 дні тому

      You wouldn't last long in my team because we use TDD every day and most of our code is written that way. Why we do it? Because it makes our life easier. Yes, writing a new feature takes more time, that's a fact. But after time, this investment pays off. Good tests that test behaviour (not implementation) give quick feedback that the new code we wrote did not break previously implemented features. It also allows you to change the internal structure of the tested module (unit) in a safe way (refactoring), so the code does not get worse over time. I think the most important part is learning how to write good tests. Here Uncle Bob shows us a simple example. A real live example where you have a module, not a class, with some dependencies, maybe infrastructure like the database or network, etc. would be better, but that's hard to do in an hour in front of 100 people.

  • @mattetis
    @mattetis 7 місяців тому

    This methodology seems so unfun and draining 🤔

    • @Dalendrion
      @Dalendrion 6 місяців тому

      At first, yes. I can attest to that. It takes significant skill in this method before it yields results. But it does allow you to prove that your work... works. (Assuming that the tests are correct.) It also helps guide you to a solution. So it can be useful in complex systems. You definitely should decide per project, or even per module in a project, whether you want to apply TDD or not. And keep in mind, having to write tests afterwards is even less fun.

    • @TheRafark
      @TheRafark 28 днів тому

      Programming isn’t supposed to be fun. It’s a job.

    • @jlecordier
      @jlecordier 21 день тому

      @@TheRafark Programming is fun. But successfully delivering requirements is not.

    • @tomcalver3865
      @tomcalver3865 13 днів тому

      It's actually enjoyable when you get the hang of it. It's satisfying seeing good quality code and tests grow over time, especially when a test you wrote earlier catches a bug you inadvertently introduced further down the line.

  • @gmxmatei
    @gmxmatei 9 місяців тому

    Only 3 concepts: Parameters, Subject and Informational Individual! This is the future in software!

  • @gmxmatei
    @gmxmatei 9 місяців тому

    Stack, Stack and Stack .... but the future in software is Universal Software Model! Much more simple.

  • @MatheusAugustoGames
    @MatheusAugustoGames 10 місяців тому

    Wow, I never thought about stubbing the business rules to test the UI presentation independently... tests can probably go a lot faster if the compiler is smart enough to inline the answers; and furthermore, that probably means no need for database access during UI tests!

  • @MatheusAugustoGames
    @MatheusAugustoGames 10 місяців тому

    Very fun!

  • @stephanimanikas3293
    @stephanimanikas3293 Рік тому

    😏 "promosm"

  • @camilohernandezruiz2776
    @camilohernandezruiz2776 Рік тому

    I love this guy