Paul Scarrone’s Post

I just finished reading "Test Driven Development: By Example" by Kent Beck. Before reading this book, I'd heard of the word "TDD" but wasn't really sure what it really meant, to the point where I thought in TDD, we create all the unit tests(like 50 of them) at once based on the software detailed design created in the previous step, then start writing the application code to be tested. It turned out to be incorrect. In TDD, we start off writing a very simple test case, then implement a little part of the API to be tested, then add a little more to the test, then add a little to or/and refactor the API, etc. So it resembles the process of refactoring. According to the book, the purpose of the TDD is to make us confident of our code, by running the test everytime we make changes. This way, whenever we are unsure about the change we made to the code, running the unit tests gives us the answer in seconds. This book introduces two case studies where the author demonstrates TDD, then the remaining is about the patterns and best practices. One of the things I've noticed is that, it seems to be better to use TDD in combination with the Object Oriented Design(OOD). In the book, the author starts off TDD based on the requirements for the application, not the design made through OOD. I'm sure that for some programmers like myself, this can lead the code to undesirable design over time, since I'd be refactoring and experimenting with the design of the code as I proceed with TDD process step by step. This was something that the author also admitted in the book too. Instead, with OOD done, we should have a design level class diagram, which defines public APIs to be tested. The previous books I've read about OOD mentioned that we should expect the design change even after we start coding and that's how it's supposed to be. With TDD, we can start writing unit test cases for the designed public APIs through OOD, like we are the user of the APIs. This should give us the perspective of the users of the APIs and make it easier for us to examine if the created design is appropriate. If there's anything to be revised in the design, we should be able to detect it more easily, while securing the quality of the code and the confidence of ours for it with TDD. #TDD

#softwareDevelopment #Testing #TDD #TestDrivenDevelopment One way I find it very helpful to learn writing code quickly, but rightly, is to try to attempt to build the feature or requirement I am working on using Test Driven Development, TDD. I learned with time the following: 1. I am encouraged to understand what the user asked early before even thinking about coding, and raise a few questions for clarifications, 2. Then I went through a few iterations to get the right test in place. These iterations involved discussions with users, PO and the team. So communication is key here, helping to align perspective and understanding early in the development phase, 3. Yes, write the code! I tried to write code to make the test pass. This took me through a number of iterations of fail-pass-refactor cycles. Here I was forced to think about the design of my solution, data flow and manipulation. Again, I found myself sharing my design with the team for quick feedback. So more communication, and emphasis on aligning perspectives and understanding. Now you have your code and unit test(s) completed. Push your code and created the PR/MR for code review and approval to merge with Master. These are simple baby steps, but their impact is profound and big. They will help build a structured approach to building software features. TDD might not be suitable for all cases, but no harm in trying. Push yourself and find where it stops! Here are some useful links to experience TDD in action An introduction to TDD https://lnkd.in/eiJ7Vvrd Building login form in React JS using TDD https://lnkd.in/etVkAZ-e Building RESTful APIs in Spring Boot using TDD https://lnkd.in/e-5Ntt9Q

I'm glad I'm not the only one who feels this way. High friction is not what I'm looking for when I am doing... anything really! In fact I would argue that the difficulty and tediousness of "setting up a new repo", for example, leads to high level design decisions being driven by friction. Like "let's only have a monolith because I hate spinning up new repos" level decisions. I actually like monoliths, but I don't want friction to be the reason why! There are tools to make a "template" and apply that to speed things up. But building a template like that? High friction! And what do you do when you update the template? Old projects get stuck in the past. 👴👵🧓 I don't have any answer though. It's just one of the reasons microservices have additional cognitive overhead. 🤷♂️

Debunking Myths: Is TDD Right for You? Test-driven development (TDD) is a hot topic, but is it all it's cracked up to be? This article explores common myths surrounding TDD to help you decide if it's the right fit for your development process. We'll tackle myths like: - TDD takes too much time. - It hurts productivity. - It only works for simple projects. - It eliminates bugs. - It's just another testing strategy. By debunking these myths, you'll gain a clearer understanding of how TDD can improve your development process. Ready to write better, more maintainable code? Check out the full article to see how TDD can benefit your team!

There's no place for Test-Driven Development (TDD) Test-Driven Development (TDD) doesn’t make sense to me, especially when requirements change frequently. In TDD, the idea is to write tests before the actual code, allowing for a cycle of development where the tests guide implementation. But when requirements are always shifting, I never find a point in the development cycle where TDD feels useful. When I develop a feature, I usually follow these steps: 1. Make it work: a mandatory, crappy implementation that gets the job done. 2. Make it right: a nice-to-have step, improving code maintainability and reusability. 3. Make it fast: by this point, I’m already moving on to the next class or method, driven by the need for speed. When it’s time to re-assess my work, that’s when I optimize for speed and write tests. At each of these stages, TDD creates friction. And I don’t like friction. While tests add a valuable layer of assurance, they can also slow you down. The smoother the workflow, the happier we are. In theory, you should write tests that don’t depend on your implementation, allowing you to write the test once and change your implementation as needed. That’s supposed to reduce friction, right? However, in my practice, this is challenging. You end up thinking about abstractions instead of being productive and pushing out more customer-facing code. Instead of focusing on delivering features, I find myself entangled in a web of test cases and mock objects. So, this leads to more friction instead. I’ve tried TDD and have tested my code religiously before. Yet, I discovered that I spent more time in the _test or _spec files than in the files that actually implement a feature. It feels like running a marathon, only to find you’ve been looping around the same track. What many TDD proponents overlook is that tests can contribute to technical debt as well. The more tests you write, the more code you need to maintain. If you feel compelled to write a test every time you change a line, you could end up managing an Everest of tests - mountains of code that require as much care and attention as the features themselves. Ultimately, while TDD might work in stable environments, I prefer a more flexible approach to keep my workflow agile and responsive.

The design strategy of TDD (test-driven-development) originated with software. This is true. But there is a broader applicable strategy for designing 𝒂𝒏𝒚 𝐩𝐫𝐨𝐝𝐮𝐜𝐭 or 𝐬𝐞𝐫𝐯𝐢𝐜𝐞, for sale, by understanding how you will isolation-test small individual components for correctness and functionality, and then iteratively test the integration of those isolated units into the overall product/service. Many SMBs build their "widget" in its entirety first, only to uncover costly errors or customer dissatisfaction later. This is a risky proposition, drastically exacerbating the amount of very costly re-work (𝘳𝘦-𝘸𝘰𝘳𝘬 𝘧𝘳𝘰𝘮 𝘥𝘦𝘧𝘦𝘤𝘵𝘴 𝘰𝘳 𝘧𝘳𝘰𝘮 𝘤𝘶𝘴𝘵𝘰𝘮𝘦𝘳 𝘥𝘪𝘴𝘴𝘢𝘵𝘪𝘴𝘧𝘢𝘤𝘵𝘪𝘰𝘯). Saying "𝒓𝒆𝒘𝒐𝒓𝒌 𝒊𝒔 𝒆𝒙𝒑𝒆𝒏𝒔𝒊𝒗𝒆" is no trivial statement. Catching mistakes post-product-construction, but still in "development" will cost the organization 4 to 5 times that of the original work. So if you spent $1 designing & building a product or service to entire completeness, it will cost you $4 or $5 dollars to correct each mistake after the fact. If you had adopted a "test-first" mentality, inspired by TDD, the original work would have cost you about $0.15 - $0.35 more than the original dollar you will have spent without a test-first approach, with a high probability that you'd likely NOT incur much, if any, of the must more costly rework later. So, to put that in perspective of big projects/products... - you get an estimate that the development will cost $1 million - you adopt a test-first strategy and that estimate increases to ~$1.25 million --OR-- you spend the upfront $1 million and another $4.5 million, per correction, in rework You choose :) (FYI...the cost of the rework necessary to fix mistakes once they've made their way to production, in the hands of your customers, is up to 𝐓𝐇𝐈𝐑𝐓𝐘 𝐓𝐈𝐌𝐄𝐒 more expensive than the upfront development/assembly/manufacturing work!!!) Adopting a ‘test-first’ mindset from Test-Driven Development (TDD) can revolutionize your approach. By defining success criteria upfront, you ensure your processes meet expectations from the start, minimizing waste and risk. Have you tried applying a ‘test-first’ approach in your SMB? Not even sure how to go about doing that? I can help, or at the very least would love to talk about this in a deeper dive. Hit me up! (thanks Marina Alex for inspiring me to do this) the figures in this post are approximation inspired by the work from ... 𝘊𝘶𝘳𝘵𝘪𝘯 𝘜𝘯𝘪𝘷𝘦𝘳𝘴𝘪𝘵𝘺, "𝘛𝘩𝘦 𝘊𝘰𝘴𝘵𝘴 𝘰𝘧 𝘙𝘦𝘸𝘰𝘳𝘬: 𝘐𝘯𝘴𝘪𝘨𝘩𝘵𝘴 𝘧𝘳𝘰𝘮 𝘊𝘰𝘯𝘴𝘵𝘳𝘶𝘤𝘵𝘪𝘰𝘯 𝘢𝘯𝘥 𝘖𝘱𝘱𝘰𝘳𝘵𝘶𝘯𝘪𝘵𝘪𝘦𝘴 𝘧𝘰𝘳 𝘓𝘦𝘢𝘳𝘯𝘪𝘯𝘨") hashtag #Innovation #TDD #SmallBusiness #ProcessImprovement #CustomerFeedback #businessmodernization #testdrivendevelopment #SMB #businesstransformation #businessagility

Why Use TDD in API Development? 👨💻 Test-Driven Development (TDD) is a software development technique that involves writing tests for a function or feature before writing the actual code to implement it. The TDD process generally follows these steps: 1. Write a test for the function or feature you want to implement. 2. Run the test, which should initially fail since the feature or function does not exist yet. 3. Implement the code necessary to make the test pass, crafting the feature based on the failing test. TDD is a widely adopted practice in API development, and it's considered beneficial for several reasons. Here’s why it can lead to a more productive project: Clearer Understanding of Requirements: Writing a test first defines the feature's specs and helps you think through requirements and certains cases before implementation. Faster Development with Fewer Errors: Writing a test before implementing a feature helps design it efficiently and catch issues early. TDD guides the implementation, reducing errors by ensuring the code meets defined requirements. No External HTTP Request Needs: When writing a endpoint feature on the application, you won't need to use external applications for requests like Postman or Thunder, because the terminal itself already does that work. Early Detection of Dependencies and Design Flaws: When writing tests before implementation, you might notice dependencies, missing functionality, or design flaws that you hadn’t considered initially. Documentation and Communication: Tests written as part of TDD serve as a form of documentation, explaining how the API is expected to behave under various conditions. I used this technique while crafting an eccomerce API that I will later inform you more about. I reccomend it. 🙂

Test-driven development evangelists often complain that TDD isn't being adopted quickly enough. However, they themselves are often the biggest reason for it. I get it. If you are enthusiastic about TDD, of course you would want people to know how good it is! However, sometimes you should stop and think about how people will perceive your message, even if it was made with good intentions. When you say that you can't write any large-scale software without TDD, experienced engineers who wrote tons of great software and never used TDD will think you are either trying to gaslight them or you don't know what you are talking about. And there are many examples of great software written without TDD. When you say that you are doing it wrong unless you follow TDD, developers who never used TDD will see it as an attempt to question their professional competencies. Some may even refuse to have anything to do with TDD out of spite upon hearing this. When you say that TDD has been objectively proven to be a superior methodology over alternatives, those who come from a traditional science background will find at least a handful of peer-reviewed studies proving otherwise. I know at least two of these. When you advocate for extreme practices, such as saying that you must always follow TDD and your code coverage must always be 100%, TDD will be perceived as some sort of a quasi-religious cult rather than an engineering practice. And engineers tend to be too rational to willingly join a cult. Don't get me wrong. I do think that TDD is useful. I even teach it sometimes and I encourage developers to at least try it. But if you want to promote it, the above examples are not how you do it.