{
  "id": 14744696,
  "title": "I Used to Think Software Testing Was Unnecessary. Then I Started Building My Own Project.",
  "url": "https://urgent.news/2026/10/15/i-used-to-think-software-testing-was-unnecessary-then-i-started",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-10-15T17:05:47.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/buildshreyansh/i-used-to-think-software-testing-was-unnecessary-then-i-started-building-my-own-project-o33"
  },
  "original_language": "en",
  "account": "I once believed that writing tests for software, whether unit, integration, or end-to-end, was unnecessary for most projects. Developers should be able to test their own code, right? That made sense for a long time. However, when I began building my own project, The Last Deploy, I started to question that belief. How It Started I launched The Last Deploy back in late June, an open-source platform designed to teach DevOps and Platform Engineering through hands-on labs. Initially, I focused on getting things working quickly, even if it meant coding directly on the production server. This was convenient when there were no users and breaking something seemed less consequential. But as the project expanded and real users started using it, I realized this approach was flawed. The Problem With \"I'll Just Test It Manually\" Manual testing works fine for small projects. You run the application, make a change, and if everything looks good, you move on. The issue arises when your change affects something you haven't touched in a while. For example, with The Last Deploy, a change to the lab execution system could cause existing labs to fail, the Docker environment to fail to start, or the curriculum sync process to break. The CLI or backend might stop handling errors correctly, and you might not notice until someone else reports the problem. As the project grows, manually verifying everything after every change becomes increasingly difficult. This is where I began reconsidering my approach to testing. Testing Isn't Just About One Feature Testing a single feature doesn't guarantee your entire application works. When I updated the lab execution system, the new feature worked fine. But what about the rest of the system? What did I change? What still needs verification? The lab execution process itself, Docker environment setup, curriculum sync, error handling, and CLI/backend interactions. Manually checking each interaction becomes impractical as the codebase grows. Types of Tests I've learned about different types of tests that help verify the application as a whole. 1. Unit tests focus on small, isolated pieces of logic. For instance, checking if a function correctly validates lab configurations without starting an actual lab. 2. Integration tests verify that multiple components work together correctly. In the case of The Last Deploy, this could mean ensuring the backend responds appropriately to lab execution requests, even when something fails. 3. End-to-end (E2E) tests test a complete user flow from start to finish. For example, checking if a user can initiate a lab and receive the expected results through the application. 4. Regression tests confirm that functionality that worked before still works after changes. This is especially important for projects like The Last Deploy, where changes to shared code can affect multiple existing labs. My Testing Strategy I'm not planning to implement a massive testing framework overnight or strive for a specific code coverage percentage. Instead, I'm focusing on the areas where a regression could have the biggest impact. My initial priorities are: Lab execution and cleanup Curriculum synchronization and local file handling Error handling and failure scenarios CLI and backend interactions Existing functionality that could break when shared code changes The goal is to build a testing suite that gives me confidence when making changes. This will allow me to spend more time building new features rather than worrying about potential issues. What Piqued My Interest? While I still believe developers should test their own code, I've come to understand that it's not always enough. As projects grow and real users depend on the software, it's no longer satisfactory to rely on \"it worked on my machine.\" I want The Last Deploy to be a project where users can trust that updates won't break their experience. I want to build something that can evolve without fear of every change causing problems. Testing isn't just about writing code that works; it's about having confidence that the code keeps working as the project evolves. This is just the beginning of my testing strategy for The Last Deploy. I'm still figuring it out, but I'm excited to share my progress. Follow The Last Deploy on GitHub if you're interested. I'd love to hear from other developers: At what point did testing stop feeling like overhead and start feeling like a necessity?",
  "summary": "I used to think writing unit tests, E2E tests, and maintaining a proper testing suite was unnecessary for most projects. If developers write the code, can't they just test it themselves? For a long time, that made sense to me. Until I started building something of my own. How It Started At the end of June, I started building The Last Deploy — an open-source platform where people can learn DevOps…",
  "key_points": [
    "Started building open-source platform The Last Deploy in late June",
    "Real users caused issues with manual testing approach",
    "Learned importance of unit, integration, end-to-end, and regression tests"
  ],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}