Joana Jane Fernandez’s Post

"The main goal of TDD is that we're driven by specifications" and that's a communication challenge. I've seen processes where writing tests clarified expected behaviors and changed the way development and future reviews happened. You write exactly what you expect from code and we can debate on it way before we start implementing. Also, if the specifications change, the tests should change and the current design should fail. And that's a great thing! This means that the specification change 1 - was real 2 - was properly implemented in the test. If the tests pass after a specification change, something's wrong. The last part to solve is not writing frail tests which aim to cover the specifications, but end up testing implementation details.

My experience is that the major obstacle in practicing TDD is our innate propensity to overbid on work and go for the big batches. The only way to do TDD properly is to learn how to work in tiny batches.

A lot of training courses on Test-Driven Development aren’t very good. How can you tell in advance what will actually work? I recently learnt about a skill acquisition model from Marian Hartman and it was a real lightbulb moment for me. Her model explains why skills training for developers often doesn't work. I've just made a new video explaining it all using a Rubik's cube. The idea is to help you to find good TDD training. I hope you like the cameo appearance of my daughter and her Rubik's cube skills! https://lnkd.in/dYSPE7Zk

How I make TDD work for me: (not the hardcore definition) The process of TDD (writing unit tests first) requires having exact requirements about how the feature should work from the start, which is not always the case. My golden rule is to only commit code with full unit test coverage, regardless of whether the tests were written before or after the code. Remember: Your tests are for you. TDD is tool. Use it to your advantage. P.S. Do you use TDD? Share your experiences. P.P.S. Kindly repost ♻️ #TDD

I think this is my 2nd repost of post - this time with a different slant. You have to do a legacy modernisation and you think you are going to do it on a modern platform and write loads of tests with TDD. The legacy payroll or banking systems you are porting to outputs to magnetic tape. Your Problem: You don't know how to read write or mount a magnetic tape. You decide to do some sort of ETL from the legacy system. Your Problem: You don't know how to read write or mount a magnetic tape. You decide to develop on the new platform anyway and do a comparsion of results in a parallel run. Your Problem: You don't know how to read write or mount a magnetic tape. You solve all these problems and have a brand spanking new system ready to go. Your Problem: The Banks clearing house and the payroll processing companies are expecting a magnetic tape.

Implementation of TDD not only help to reliable, maintainable and less even free from bug. But it also improve and sharp the way of thinking process. While you start writing the failing test it will trigger your brain to think possibility test case will come naturally. the more you practice the more strong the analyze #TestDrivenDevelopment #ImproveDaily

Why not mock in TDD Short answer TDD's primary win is writing better code. NOT writing tests for safety. NOT testing first for better tests NOT testing first for better requirements alignment It's for writing better/more maintainable code -- code that would be ChEFS* to change even if you burned all the tests. Mocking leads you away from that central goal during TDD by allowing worse code to be tested easier. *ChEFS => Cheaper Easier Safer Faster

What's the real cost of your TDD workflow? While coding katas are the perfect playground for test-driven mastery, production code demands pragmatism. If your tests are becoming a burden rather than a benefit… It's time to cut the fat.

Today I said something during a conversation about testing that sounds insane, but highlights the difference in a TDD mentality. Them: "You need to make sure you can run the application in your local environment". Me: "No you don't. You only need to make sure it runs in production." Them: "Then how do you debug the application." Me: "You don't." *Audible confusion* The other person is not dumb in the slightest. It's just difficult to understand the TDD perspective if you've never done it. Everything a TDD person says sounds insanely impossible.

🌟 **What I Learned This Week: Testing and CI/CD Pipelines!** 🌟 Hey everyone! This week has been super exciting and full of learning. I've been diving deep into Testing and Continuous Integration/Continuous Deployment (CI/CD) pipelines, and I wanted to share my journey with you all. 🔍 **Here’s What I’ve Been Up To:** [] Got a solid understanding of different testing methods like unit testing, integration testing, and end-to-end testing. [] Learned how to set up and optimize a CI/CD pipeline to make our development process smoother and deployments a breeze. 💡 **What I Accomplished:** [] Successfully implemented a CI/CD pipeline using GitHub Actions for my project. [] Did some serious unit testing to ensure everything is running perfectly. You can check out my project here: [Laptop Lounge](https://lnkd.in/gp_WkV_M). I’m really excited about how much more efficient and reliable our development process has become thanks to these new skills. Continuous learning and hands-on practice are so important in our field, and I'm thrilled with the progress I've made. Thanks for reading, and stay tuned for more updates! #Golang #Testing #CICD #GitHubActions #LearningJourney #DeveloperLife #LaptopLounge #BROTOTYPE