As a QA engineer, one of the best things that you can do to piss off a developer is to start learning a programming language! Because s/he knows, now you will not question the product or slap him with bugs only; you will ask him to teach you a programming language as well. Aside from the jokes, I plan to document my Golang journey for 2025, as it’s a special year for me. Golang is one of the soft skills that I want to have confidence in.

Why GO?

If you thought I would write the same bulls**t that is available everywhere, you are wrong. I liked Golang because I like their logo. Is that reason enough to learn a programming language?

Analogy of Go Project Structure

I thought this was the most suitable piece with which I could start off my diary. I always get overwhelmed when I look into even a simple application project structure. So, taking my to-do web app (yet another in progress but in Go) project structure for the analogy. Typically, it looks like this (phase 1).

├── cmd/
│   └── server/
│       └── main.go
├── internal/
│   ├── handler/
│   │   └── task.go
│   ├── model/
│   │   └── task.go
│   └── store/
│       └── memory.go
├── web/
│   ├── templates/
│   └── static/
└── go.mod

A restaurant analogy has cleared it up for me to understand. Let’s think of a cafe. A cafe will have a front door to enter, waiters to wait the table, a menu to choose items, and a dining space to eat.

The Front Door (cmd/server/main.go)

Like any other establishment, our cafe would need a main entrance. This is like any other programming language as well. main.go is where everything starts. Also, as a QA engineer, this is where I’d start my integration tests.

The Wait Staff (internal/handler)

I typically prefer self-service restaurants or cafes. But in general, there will be waiters. It’s the same for our Gopher’s Cafe (yeah, let’s call it that). The handlers are like the waiters. Why?

• They receive orders (HTTP requests)
• Validate the order (I cannot ask for a long island iced tea in a cafe just because it has tea in it’s name.)
• Pass the orders to the kitchen
• Bring back the food (response)

When we write API tests, we’re essentially ensuring if the waiters are doing their job correctly or not.

The Menu (internal/model)

As it’s up to our imagination, let’s give our Gopher’s Cafe a proper menu that is equivalent to the Golang model. Because:

• Available items show up (data structures)
• Ingredient they have (properties/fields)
• Probability of customizations (methods)

Would I be able to taste margarita if it’s not on the menu? Similarly, I won’t test for data structures that aren’t defined in models.

The Kitchen (internal/store)

The store is the kitchen of our Gopher’s Cafe, where all the magic happens. It’s responsible for:

• Preparing ordered foods (storing data)
• Plating dishes (retrieving data)
• Inventory management (managing data)

And this is where I focus my unit tests. Is the data being stored correctly? Is it being retrieved? Are we handling errors while managing data?

The Dining Room (web/)

This is what an end-user sees and interacts with typically. It can have:

• Table layouts (templates)
• Decorations (static files)
• Ambience (css/js)

This is an equally important testing scope. Is the UI intuitive and responsive? Does it look good on desktop as well as mobile?

Why This Analogy Works for QA Engineers

Because we’re used to thinking about:

• User flows (customer journey throughout the restaurant)
• Data validation (order accuracy)
• Error handling (dealing with special requests)
• System integration (kitchen-waiter communication)
• Performance (service speed)

Now, this is a v1 of an analogy where I expect wrong concepts as I’m learning my way through it. Feel free to point it out.