The cmp package is the only package outside the Go std library that we need to test and document how the system behaves. But to ensure we describe tested behaviour, it’s good to run all the tests with gotestdox. So, what do your tests look like? Does everyone on your team understand what they test?
Having clear, easy-to-understand and rock-solid test preconditions is paramount. It’s like making sure your car lights and battery are working before swapping your credit card and signing up for the annual car inspection.
This time, we’re rolling up our sleeves to simplify the test setup, pick Go types that actually make sense, and stop confusing readers with constantly changing names.
Why do we clutter our code? Are our standard tools sufficient? If so, we can move on to what truly matters—designing tests that accurately verify the desired behaviour.
Welcome to the Go podcast with host Dominic St-Pierre! In this episode, Dominic and I discuss the most common testing mistakes that Gophers make and explore my newly launched book, “ 50 Go Testing Mistakes .”
Errors in Go are like the STOP sign. They send a strong signal to avoid disasters. Just like the Go error yelling don’t trust returned value, don’t use it .
Welcome to the Go podcast with host Dominic St-Pierre! In this episode, Dominic and I chat about using Go in cybersecurity, DevSecOps, and testing. Whether you’re an experienced developer or just curious about Go, there’s something for everyone. Let’s dive in!
“I have two news for you, bad and worse,” said the mechanic. “The battery is dead and I won’t get a new one until Monday. Forget about your annual inspection today,” he continued. “But…” you started. “There is no but.” he cut short. No setup, no testing. Just like in your Go program.
We focus on fundamental parts of the cmp package: checking equality and calculating diffs. With a small change, you increase test efficiency more than 7x. Yes, over 700% faster. Why work harder, not smarter?
In Go, we build packages - fundamental Lego-like blocks that we assemble in modules and use to build applications. That’s why it’s crucial we start designing packages by modelling their public APIs. Let’s roll up our sleeves, sharpen the scalpel and start the second code surgery. This time, we focus on tests.
The ritual starts. JIRA, jira tickets everywhere. As you are not a newbie in the tech game, you listen, watch, analyse and spot behaviour patterns. Initial excitement fades away. Why? What are the red flags?
A few years ago, at the GopherCon UK conference, I asked three programming instructors and mentors a straightforward question: What early career mistake will you never make again?
For us Go developers, writing less code means fewer opportunities to make mistakes. But how about achieving more by doing less? That sounds appealing. Isn’t it? And how about spending less time writing code to force the compiler not to optimise the benchmarking functions?
How do you know if what you are building is the right thing? How do you know if the product you just put into customers’ hands doesn’t harm them? Don’t put them into hospital or worse, kill them?
I’ve been interested in engineering quality since I assembled my first electronic radio over 40 years ago. Since then, I’ve explored how focusing on the quality of work in the electronics, electric, and automation industries affects the products I put into people’s hands.
Thinking is hard. Who wants to do this nowadays? Who doesn’t rush to build software, ship and collect the paycheck? So, don’t bother about designing the product first. Just ship! Ship fast and break things!
When was the last time you were fixing critical bugs in your code? Were you confused and mad that something wasn’t working? Did you feel angry or curious?
You skyrocket your chances for success if you follow simple rules. The Go programming community at the Bitfield Institute of Technology (BIT) call them the 10 commandments of Go. Ready to dive in?
“Our reports say your software is not secure and has critical and high vulnerabilities. Our delivery pipeline is not working. We can’t upgrade applications in production environments!”. You see Slack messages and Salesforce escalation tickets. It doesn’t look good. How do you react? What’s your next step?
How should I organize my Go code? What directories to create? How many nesed levels? Where to put what files? How about tests and test data? Shall I follow this and that template? Could we automate project structure generation?
Imagine you are sitting relaxed in a self-driving car. You are taking a sip of your afternoon tea. You are going to your friend’s wedding. You’re getting closer to a crossroad, and your car is about to change direction. Suddenly, the car detects an obstacle on the road—a fallen tree! How can you not panic?
Before writing Go programs, you must set up your editor and install essential tools. A short list includes staticcheck , gosec , govulncheck , and gofumpt .
Users won’t do this! No way! Why would they enter such values? It doesn’t make sense! Does it sound familiar? How many times have you said it to yourself? Well… You are about to see and learn how a missing test puts thousands of production Kubernetes systems in danger.
It takes ages for the newsfeed to load. Scrolling on the tablet is slower than usual. Applications aren’t starting as quickly as they were a week ago. You’re getting frustrated. You recall the last change you pushed to production. No, it couldn’t be that simple change. Are you sure?
Have you ever wondered how to determine if your Go code is performing at its best? Benchmarks help you spot slow code and fix it. They also help you choose the best data structures and algorithms. By the end of this book, you will know how to write benchmarks that guide your engineering decisions.
What does it mean to keep security in mind when writing Go code? Answering this question in one short article seems impossible. For this reason, we’ll narrow it down to a few specific practices.
Building and releasing software shouldn’t be a tedious, manual, error-prone task. I am presenting an automated way to build and release Go libraries and command-line tools for different operating systems.