Run an application. Click a few buttons. If the terminal doesn't have errors, then everything is working. Right?
What's the point of writing tests if all seems to be fine. Let's explore testing discipline and why it's a habit every developer should build early.
What is Testing Discipline?
Testing discipline is the habit of verifying that your code works. It's not something you do at the end of a project.
It's something you build into your development process.
The goal is simple. Catch bugs as early as possible. A bug found while writing code usually takes minutes to fix.
The same bug found in production can take hours to investigate, reproduce, and resolve.
The earlier you find problems, the less expensive they become.
Different Types of Tests
When people talk about testing, they're usually referring to three categories.
The first is unit testing. A unit test checks a single piece of functionality, usually a function or method. These tests are fast and easy to write, making them the best place for beginners to start.
Next are integration tests. These verify that different parts of your application work together correctly. For example, does your service communicate properly with the database?
Finally, there are end-to-end tests. These simulate a real user interacting with the application from start to finish. They provide the most realistic results but are usually slower and more complex.
As a beginner, I recommend that you should focus on unit tests first.
Different Testing Approaches
As you continue learning, you'll come across different testing methodologies.
One of the most popular is Test-Driven Development, often called TDD.
The idea is simple. Write the test first. Watch it fail. Write enough code to make it pass.
Many developers like this approach because it forces them to think about requirements before writing implementation details.
You may also hear about Behaviour-Driven Development, or BDD.
This approach focuses on describing behaviour in a way that both technical and non-technical people can understand.
Then there is static testing and dynamic testing.
Static testing involves reviewing code without running it. Code reviews and linters fall into this category.
Dynamic testing involves running the application and verifying its behaviour.
Both have their place in a healthy development process.
Writing Tests in Go
One thing I like about Go is that testing support is already built into the language. You don't need to install any package just to write your first test.
There are a few rules to remember.
- Test files must end with
_test.go. - Test functions must begin with
Test. - They must also accept a
*testing.Tparameter.
For example:
func TestCalculateDiscount(t *testing.T) {
// test logic
}
Once you follow those rules, Go automatically recognizes your tests.
A Simple Example
Imagine you're building an e-commerce application.
You have a function that calculates discounts based on order value.
Your code works for normal orders, but what happens if someone enters a negative amount?
What happens at the discount threshold?
What happens for large purchases?
These are the kinds of questions tests help answer.
A common pattern in Go is called table-driven testing.
Instead of writing separate tests for every scenario, you place inputs and expected outputs into a table and loop through them.
This allows you to test multiple situations without repeating large amounts of code.
It's one of the most common testing patterns you'll see in Go projects.
Running Tests
Once you've written a test, running it is simple.
To run all tests:
go test
To see detailed output:
go test -v
To check test coverage:
go test -cover
When you're starting out, go test -v is usually the most helpful because it shows exactly which tests passed and which failed.
Making Testing Part of Your Workflow
Writing a few tests is useful. Whenever you add a feature, write tests for it.
Whenever you fix a bug, consider adding a test that prevents the same bug from returning.
Over time, your test suite becomes a safety net.
You can refactor code, improve performance, and add features with much more confidence because the tests will alert you if something breaks.
This becomes even more important when using CI/CD pipelines.
Tests can run automatically whenever code is pushed, helping catch issues before they reach production.
Why Testing Matters
I know testing can feel slow at first.
When you're excited about building features, writing tests can seem like extra work.
But after spending hours debugging issues that a simple test could have caught in seconds, my perspective changed.
Tests give you confidence.
They make refactoring safer.
They help identify bugs quickly.
They also act as documentation by showing exactly how a function is expected to behave.
Most importantly, they help you deliver software that actually works.
Conclusion
Many beginners see testing as something they'll learn later.
The truth is that testing is one of the habits that helps you grow from a beginner into a reliable developer.
You don't need to test everything immediately.
Pick a function you've already written and create a few test cases for it.
Test the normal case.
Test an edge case.
Test an error case.
Run the tests and see what happens.
The more often you do this, the more confidence you'll have in your code and the less time you'll spend chasing bugs in production.