Vish's Journey in Computer Science

As part of my Software Quality Assurance and Testing course, I recently explored the concept of testing with stubs. To deepen my understanding, I referred to the article “Test Doubles: Stubs, Mocks, and Fakes” from Martin Fowler’s website.
Link: https://martinfowler.com/bliki/TestDouble.html

This resource explains different types of test doubles, including stubs, and how they are used when testing dependent components. A stub is a simplified implementation of a class that returns predefined values, allowing us to test another class even when its dependencies are incomplete or not yet implemented. The article also distinguishes between behavior-based testing (checking interactions between objects) and state-based testing (checking outputs or state changes).

I chose this resource because I wanted a clearer and more practical explanation of stubs beyond classroom slides. Sometimes lecture content feels abstract, and I was looking for something that connects theory to real-world software development practices. Martin Fowler is also a well-known expert in software engineering, so I felt his explanation would be reliable and insightful.

From this resource, I learned why stubs are especially useful during early development stages. For example, if a class depends on a database or external API that is not ready, we can create a stub that mimics expected behavior. This allows testing to proceed without waiting for the full system. I also understood the difference between verifying outputs (state-based testing) versus verifying interactions like whether a method was called (behavior-based testing). This helped me connect stubs with other testing concepts like mocks.

One important takeaway for me was how stubs improve productivity and support incremental development. Earlier, I used to think testing could only happen after everything was implemented. Now I realize that with stubs, testing can happen in parallel with development. This is especially useful in team environments where different members are working on different modules.

I also found the idea of output capture interesting. By capturing console output or logs, we can verify whether the correct method in the stub was called. This gives a simple way to perform behavior-based testing without complex frameworks.

Going forward, I plan to apply stubs in my own projects, especially in my capstone project where multiple components depend on each other. Instead of waiting for all modules to be complete, I can use stubs to simulate dependencies and continue testing early. This will help me write more reliable and maintainable code. Overall, this topic has changed how I think about testing. It is not just a final step, but something that can be integrated throughout the development process.