Improving your Test Driven Development in 45 minutes - Jakub Nabrdalik

Sdílet
Vložit
  • čas přidán 19. 06. 2024
  • I’ve been using TDD/BDD at work for the last 12 years, I also teach and mentor teams on this subject. I’ve found that misconceptions and errors in this field are shared, and that most of us make the same mistakes. Give me 45 minutes of your time, and I’ll try to address the most common problems, hoping to improve your TDD/BDD situation as much as possible.
    I’ll try to solve:
    Long running tests problem, by bringing back the correct shape of test-pyramid with power of Hexagonal Architecture (Ports & Adapters) with practical examples in Spring.
    Miscommunication and lost art of requirement gathering, by focusing on readability, introducing just enough of Domain Specific Language, and sorting out what is important with the power of Spock.
    Difficult test setup and environment requirements, by using command and conquer, modularity, monitoring.
    Mock abuse, by showing what are the benefits of in-memory implementations.
    And hopefully more.
    Most teams that do not write tests first do it, because it’s hard for them. I’ll try to show you, how to make it easy. Real life examples included.
    If you are not using TDD/BDD, this might also interest you - you’ll know how to start the right way.
  • Krátké a kreslené filmy

Komentáře • 34

  • @pengdu7751
    @pengdu7751 Před 4 lety +33

    one of the videos that sounds great even at 1x speed. great presentation.

  • @0xSerg
    @0xSerg Před 3 lety +11

    It's one of the best TDD video I've been watching last years.
    Described problems are real and Jakub explains great solutions.

  • @JDLuke
    @JDLuke Před 5 lety +33

    This video should have more views and likes than it does. The presenter makes very important and logical points which can be applied to a wide variety of systems under development.

    • @Manishsharma-tj4nn
      @Manishsharma-tj4nn Před 3 lety

      Even I think so, but I do not understand those dislikes, they confuse me ?

    • @szigyartom
      @szigyartom Před 3 lety

      @Ivana Jetter Cool, your girlfriends insta has nasty pictures. I've never thought ..

    • @ALinuxed
      @ALinuxed Před 2 lety

      @@Manishsharma-tj4nn They did not test.

  • @vladislavvinnik9871
    @vladislavvinnik9871 Před 5 lety +5

    Brilliant talk.

  • @micha8617
    @micha8617 Před rokem +2

    "Business is not trained in logical thinking"

  • @jpalvis86
    @jpalvis86 Před 4 lety +9

    Great talk, I'll surely repeat it a couple of times to understand it better and start improving my TDD skills!

    • @Manishsharma-tj4nn
      @Manishsharma-tj4nn Před 3 lety

      Please share link or topic of other related videos to learn more

    • @soymichelo75
      @soymichelo75 Před 3 lety +1

      @manish look for the talk of sandro mancuso he mentioned and also "full hour with Uncle Bob", (and follow also youtube suggested videos) I hope it helps you :)))

    • @roktitovsek3024
      @roktitovsek3024 Před rokem +1

      @@Manishsharma-tj4nn there's a cool presentation by Ian Cooper (TDD, Where Did It All Go Wrong).

  • @maciejpawlaczyk8383
    @maciejpawlaczyk8383 Před 3 lety +2

    This guy first has been using approaches he presented for quite some time. So this is the knowledge based on practice, and he's pretty smart, then conclusions are worth to look at.

  • @cseshivaprasad1985
    @cseshivaprasad1985 Před 5 lety +5

    Awesome video on TDD. Can someone please share the GIT link as well ?

  • @jmrah
    @jmrah Před 2 lety

    Great presentation chock-full of good advice and good examples! The only thing I wasn't impressed by was his dismissal for the need of contract tests when he answered an audience members question around the 53min mark.

  • @DodaGarcia
    @DodaGarcia Před 2 lety +1

    This surprised me with how much I didn’t know about unit testing. Dude is super handsome too.

  • @jmlane
    @jmlane Před rokem +1

    This talk doesn't seem very relevant to TDD™, but it does raise some interesting unit and integration testing techniques. Stay for the questions; the speakers clarifications on IO testing misunderstandings are valuable.

  • @thatpaulschofield
    @thatpaulschofield Před 4 lety +1

    What language are the BDD tests written in? Groovy?

  • @tonylegge7261
    @tonylegge7261 Před 3 lety

    Great talk - just makes you realise how much better Golang is for coding!

  • @TheOceanLoader
    @TheOceanLoader Před rokem

    It's a real buzz when I watch talks and realise I have worked with some of the developers cited.

  • @phyzix_phyzix
    @phyzix_phyzix Před 2 lety

    Single level of abstraction principle

    • @corlaez
      @corlaez Před 2 lety +1

      Why do you mention the name of the principle? Do you think that the code and approach shown uses it?

  • @SergeyRyabenko
    @SergeyRyabenko Před 2 lety

    Changing method signator breaking existing code? NO WAY, I have to re-inspect my way of coding.

  • @MinNyeAccount
    @MinNyeAccount Před 3 lety +5

    have been watching a few talks on TDD and it seems there is just as manny opposing views on the topic as if it was politics

    • @danielwilkowski5899
      @danielwilkowski5899 Před 2 lety +1

      TDD was inspired by Kent Beck in his book "Test driven development". Anything different than that is just misquotation and should be reffered to by a different name.

  • @drcl7429
    @drcl7429 Před rokem +1

    Not sure what he's talking about but it's certainly not TDD.

  • @Tony-dp1rl
    @Tony-dp1rl Před rokem

    Sadly, like all other TDD presentations, it starts from the unproven premise that developer-tests are a better, more effective, method to testing compared to the other approaches that often get more coverage, and provide more confidence before deployment. Hardly anyone writing software that cannot fail without huge costs is saying "developer's mocked unit tests passed, deploy it". Just once I would like to see some sources that show the WHY of TDD cost-benefit-wise, not the HOW. For the HOW, these videos are great.

    • @ForgottenKnight1
      @ForgottenKnight1 Před 2 měsíci

      If you have multiple test types, coverage should not be cummulative. That is a naive way of seeing coverage. Developers might not write all the acceptance or e2e tests, but they should be involved in everything that is done using automation. You can have SDETs doing exploratory, showcasing, some UAT, or demos manually.

  • @lightfeather9953
    @lightfeather9953 Před 3 lety +2

    A shitload of code just because of many test cases? Ruins his credibility as how has he not been exposed to modern test frameworks that have setup and teardown methods that can be used by multiple tests.

    • @marcinwolak241
      @marcinwolak241 Před 3 lety +14

      You shouldn't use setup & teardown methods, because then you're losing context. You cannot read test from top to bottom, because there are special functions like setup and teardown - for each test case you'd have to remember about them, what they are doing. These functions are considered as anti-pattern.

    • @ForgottenKnight1
      @ForgottenKnight1 Před 2 měsíci +1

      @@marcinwolak241 "You shouldn't use setup & teardown methods, because then you're losing context" - debatable. I would say that those who advocate such do not have a strong basis. Test code is code and should be mantained like any other piece of your codebase. One important aspect of maintenance is reducing duplication, while keeping the code easy to navigate. If the setup and teardown are complicated when doing anything less complex than an acceptance test, this should be a red flag that your design should be reviewed and improved.

  • @orlovskyconsultinggbr2849

    Man this guy is misleading, if you dont write test first , you dont doing TDD. Sure its hard when you need to write tests after the code has be written and this is not TDD again. So what you do ? Right, you start writing failing test and pass them one by another and in parallel you improve the codebase and refactor it , if business say dont do TDD you ask them politely : do you want that i create mess? if they say yes, you update your resume and apply at another company, because your company would not live long. Another problem is dependency on Spring framework , for me its a smell of bad design, so dont integrate your business rules into the framework and make sure that you do them via open close principle, open for extension, but close for modification or even use proxy pattern. Why dont depend on framework? Well frameworks go and get out and at some point it can get you into difficult situations and if you get in such case , well blame on yourself you get it handed to you.

    • @todayisagoodday5027
      @todayisagoodday5027 Před rokem

      what would you recommend as a good TDD study in java for a beginner about to hit the market. I'm already in school but wanted some to the point information.