Why I don't write a test for every function

Don’t Repeat Yourself (DRY) A Little Reminder for Developers Been a while since I posted here, but I just want to drop something short and real. If you ever find yourself writing the same logic inside two or three different methods in a class, just stop. You don’t need to copy and paste that block of code everywhere. Just extract it into a private method, and call it wherever it’s needed. Simple. This one habit alone makes your code: ✅ Cleaner ✅ Easier to maintain ✅ Less prone to bugs For example, instead of writing the same validation or formatting logic across multiple functions, move it into one method and reuse it. That’s what the DRY principle means: Don’t Repeat Yourself. Because when you repeat code, you’re not only repeating logic, you’re also repeating future errors. Keep your code dry, your brain fresh, and your debugging time short.

A clean code is not always the perfect code..😕 A most optimal solution to a problem may not always be a simple trick as compared to brute force solution...😐 But, always chasing behind "perfect" and the most "optimal" code never got me anything, it rather taught me how to think in terms of brute force solution first. And i learnt it the hard way 😫 , always wasting time on thinking on most "optimal" solution, rather focusing on brute force solution first, because it is impossible to build a house without a rough framework.. So, for anyone out there, doing the same mistake like me - Please stop it, because by the time we will realize it ourselves, we regret upon time passed which could be used to water our productive time.🌱

my thoughts on writing tests what you should test for: - renders and matches this snapshot - has proper elements/structure present - config options affect it this way - defaults kick in when no config is provided - custom validators work for both positive and negative case - methods do what they're supposed to do; given correct input, correct output is returned - error handling works Reading the tests should give the answer to "What does this do and how does it do it?" couple of guidelines: - write good descriptions because that's the first thing someone (including yourself) sees - avoid stateful tests at all costs; don't make one test depend on the actions performed in the previous test -- always reset - make use of setup / teardown hooks; avoid doing it in the tests themselves -- use before/after beforeEach/afterEach or whatever the framework provides - duplication is good, don't abstract and refactor and compact and extract too much, especially in setup/teardown code -- it makes tests hard to traverse what am I missing?

There are multiple ways to group subtests in Go. But often enough, I see folks pulling in a third-party library just for that. With a bit of discipline, most of the time you can avoid 3p libs for this. Did a comparison between several ways of doing it. https://lnkd.in/ey3MtMyE #golang

🧠 Developer Philosophy: var_dump() is not a debugging tool — it’s a way of life. 🤓📜 Sure, you could use proper logging, breakpoints, and nice debugging tools… …but nothing hits quite like a raw var_dump() wrapped in <pre> tags. 💅🐘 (Bonus: It’s not a bug — it’s beautifully formatted chaos.) 😎🔥

Think you need an `if` statement to run code conditionally? Wrong. Use short-circuiting: `isReady && startProcess()`. The function only runs if `isReady` is `true`. But it's a trap. One unexpected falsy value (`0`, `''`, `null`) and your critical function never runs, silently failing. Is this a sleek, expressive pattern, or a lazy way to write brittle, bug-prone logic? #GaboTips

Exceptions aren't evil. Well, not totally evil. I think there can be a time and place for throwing exceptions. One of the complications that I see is that when developers consider smaller modules of code, something might be considered exceptional to them from the perspective of that module. However, when you start building more complex systems by combining some of these modules, is it still exceptional behavior in the grand scheme of things? Watch the full video here: https://lnkd.in/dwY4runn

🔹 Day 47 of #100DaysOfLeetCode 🔹 ✅ Problem: 141. Linked List Cycle Difficulty: Easy 🟢 Topic: Linked List 📌 Problem Statement: Given the head of a linked list, determine if the list contains a cycle. A cycle exists if by following next pointers you can revisit a previously visited node. ⚡ Approach: Use Floyd’s Cycle Detection Algorithm (Tortoise and Hare). Move one pointer (slow) by 1 step and another pointer (fast) by 2 steps. If they ever meet, there’s a cycle. If fast reaches the end, no cycle exists. 🧠 Example: Input: head = [3,2,0,-4], pos = 1 Output: true ✅ 🕒 Time Complexity: O(n) 💾 Space Complexity: O(1) ⚠️ Silly Mistake I Made: I wrote this in the while loop: while(fast != nuall || fast.next != null || fast.next.next != null) ❌ Mistakes: Used || (OR) instead of && (AND). Added extra fast.next.next != null unnecessarily. Also misspelled null. 😅 while(fast != null && fast.next != null) 👉 This mistake made the loop run incorrectly and caused errors. 💬 Lesson Learned: ⚡ Small syntax or logical mistakes in conditions can break your entire logic. Always double-check loop conditions carefully! #Day47 #LeetCode #LinkedList #FloydsAlgorithm #DSA #100DaysOfCode #CodingChallenge #BugFix

**Clean Code** * Your Code must be readable by other programmers. * This is not simply a matter of writing nice comments. * It requires that you craft the code in such a way that it reveals your intent. * This is hard to do. * Indeed, this may be this most difficult thing a programmer can master.

Good unit tests go beyond catching bugs—they make your codebase more reliable, scalable, and maintainable. This blog explores practical techniques for writing unit tests that solve real problems, not just add overhead. Read the blog: https://lnkd.in/g7Ck7D6e