Video není dostupné.
Omlouváme se.

Why Software Engineers Love Test Driven Development

Sdílet
Vložit
  • čas přidán 14. 08. 2024
  • Ever wondered about the impact of Test-Driven Development (TDD) in software engineering? Dive into the world of TDD as we explore its efficiency and debunk common misconceptions. From addressing "what is TDD" to unveiling why TDD is worth embracing and understanding whether "TDD is dead," this video guides you through a LeetCode problem, demonstrating the TDD loop in action.
    Discover the reality behind the myth that TDD takes longer and explore its efficiency in accelerating development. Delve into how TDD contributes to seamless API design, ensuring code that is not just readable but also easy to use. Explore the time-saving benefits of TDD, a stark contrast to manual testing, and unlock its versatility beyond unit testing in front-end development, machine learning, and data analytics. We'll also address the question of "why would anyone hate TDD" and explore where "TDD might go wrong."
    Immerse yourself in the TDD mindset, a transformative approach that ensures robust code and fosters continuous improvement. Experience firsthand why TDD is more than just a testing practice-it's a methodology that enhances code reliability and accelerates development. Ready to transform your software development approach? Watch now and embrace the TDD journey!
    🚶‍♂️ FOLLOW ME 🚶‍♂️
    Join Our Discord - / discord
    Twitter - / codyengeltweets
    TikTok - / codyengeltalks
    Medium - / membership
    Subscribe To My Newsletter - www.engel.dev/
    🎥 My CZcams Gear - kit.co/CodyEng...
    🖥 My Desk Gear - kit.co/CodyEng...
    🎵 My Background Audio - www.epidemicso...
    *The above links are affiliate links.
    📚 RESOURCES 📚
    Test Driven Development is Fundamentally Wrong - hackernoon.com...
    Why We Shouldn't Use TDD - sam-redmond.co...
    LeetCode Problem - leetcode.com/p...
    ⏰ TIMESTAMPS ⏰
    0:00 - Intro
    0:28 - Writing All Of Your Tests Upfront
    3:30 - Test Driven Development Takes Longer
    4:42 - You Shouldn't Write Code For Your Tests
    5:48 - Manual Testing Is Time Consuming
    7:14 - Not Just For Unit Testing
    #softwareengineer #softwaredeveloper

Komentáře • 14

  • @ddaypunk
    @ddaypunk Před 6 měsíci

    Given we used TDD at work, and my history as a tester, I like how it is described here. A big piece of this is truly writing the right tests, the right way. Meaning that they can actually fail and notify you of defects. Combining this with pair programming to write what we considered the contract in Android, the ViewModel, really sped things up in the long run. It was nice to have a decent set of tests by the time we started adding the View and Data layers separately from the other developer. When changes would inevitably be needed in the viewmodel by one of us, we had a safety net ready to be added to and run for said changes giving us better confidence in said changes.
    Agreed though, there is no reason for 100% coverage up front, nor is it really that realistic or useful.

  • @mdxggxek1909
    @mdxggxek1909 Před 6 měsíci

    writing test first improves my productivity massively, since I have a clear goal to work towards and don't get distracted

  • @stanleychukwu7424
    @stanleychukwu7424 Před 6 měsíci

    been a hot minute cody, where you been? Happy new year to you my boy, and whats up with the hair style/cut?

    • @CodyEngelCodes
      @CodyEngelCodes  Před 6 měsíci +1

      It sure has been! I bought a house, and was severely burnt out from work (also should answer the haircut question 🤣) but excited to finally be back.

  • @juanmacias5922
    @juanmacias5922 Před 6 měsíci

    I'm building a back end for a bug tracker personal project, and using as close to TDD as I can has been amazing, it has illuminated most of the manual testing, and after any refactoring I get a quick answer on if I broke anything lol

    • @CodyEngelCodes
      @CodyEngelCodes  Před 6 měsíci +1

      That's really awesome to hear and good on you for trying something new with your personal project! It doesn't sound like this is the case with you, but remember that TDD is a tool, don't be hard on yourself for not using it 100% of the time. The important thing is you know how to use it and have the freedom to decide when it's appropriate to use.

    • @juanmacias5922
      @juanmacias5922 Před 6 měsíci

      ​@@CodyEngelCodes oh for sure, that's the fine line with any kind of practice, keeping in mind when it could become a hindrance, and that no one way is the only way. At this point it's helping me move faster than if I had to check each individual end point using postman, so I currently think it's great, I've just never been able to wrap my mind around how TDD could be used to make UI, although I'm starting to think a TDD form of end to end testing could be helpful even in UI building. Testing in general really helps me feel that the app won't crumble as I'm adding features lol thanks for the video!

    • @CodyEngelCodes
      @CodyEngelCodes  Před 6 měsíci +2

      You are very welcome for this video!

  • @pavelcistjakov243
    @pavelcistjakov243 Před 6 měsíci

    Thank you for great explanation, Walter White!

    • @CodyEngelCodes
      @CodyEngelCodes  Před 6 měsíci +1

      You are very welcome! Now I need to get back to cooking.

  • @hadem4217
    @hadem4217 Před 4 měsíci

    I don't agree that TDD is any more useful than just writing your code before tests. At least for anything that isn't trivially simple like the function you demoed.
    Fact is, your tests will inevitably depend on your implementation (think class design, helper functions, edge cases), which isnt always clear until you implement.
    Even if i agreed, writing tests and iterating one at a time is a waste of time compared to writing as many tests as you can think of first.

    • @CodyEngelCodes
      @CodyEngelCodes  Před 4 měsíci +1

      If you have several test cases in mind there is nothing stopping you from writing those at once. And as your implementation changes you have three options:
      1. Change the test because the BEHAVIOR also changed.
      2. Don't change the test because only the underlying implementation changed.
      3. You might need to update the function being called in the test or the parameters because the API changed, however most of the time a refactor tool will do that for you.

  • @elidas1008
    @elidas1008 Před 6 měsíci

    Heat hear