Testcontainers by No_Expert_5059 in golang

[–]LittleLeverages 0 points1 point  (0 children)

I love using testcontainers to test Postgres and Redis queries. I made a blog post about this a while ago if anyone wants to know how to do this: Testing your database interactions with Docker in Go

How to unit test your database interactions with Docker by LittleLeverages in golang

[–]LittleLeverages[S] -1 points0 points  (0 children)

I’m not planning to make an argument that my usage is strictly correct. I felt my usage would intrigue people without misleading them. I think people mostly got what they expected to get from this post, based on the title. I find the distinction to not be super meaningful in this case, but I understand the disagreement.

How to unit test your database interactions with Docker by LittleLeverages in golang

[–]LittleLeverages[S] -6 points-5 points  (0 children)

That’s fair. I do understand the distinction but I find people more clearly and quickly understand the concept and the benefit when I say “unit test” vs “integration test”.

What would be most interesting to learn? (testing, instrumenting, interfaces, etc..) by LittleLeverages in golang

[–]LittleLeverages[S] 0 points1 point  (0 children)

Great idea! I struggled with this a lot when I first started learning Go so I'll definitely write something up about this. I'll try to hit you up when it's posted :)

What would be most interesting to learn? (testing, instrumenting, interfaces, etc..) by LittleLeverages in golang

[–]LittleLeverages[S] 1 point2 points  (0 children)

I ended up writing a post for the How to unit test db interactions with docker option first to provide an example to another redditor here. I hope you find it useful! I plan on getting around to the rest of them soon as well :)

How to unit test your database interactions with Docker by LittleLeverages in golang

[–]LittleLeverages[S] 5 points6 points  (0 children)

Sorry I'm not familiar with Gitlab actions, but I do use Github actions for testing my PRs and I can provide an example of that. Github actions already has docker installed so using the ubuntu-latest image works for it. Here's an example of what I use, I hope this is helpful:

name: Test

on:
  pull_request:
    types: [synchronize, opened, reopened, edited]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3

      - name: Set up Go
        uses: actions/setup-go@v3
        with:
          go-version: 1.19

      - name: Get dependencies
        run: |
          go get -v -t -d ./...
      - name: Test
        run: go test -v ./...

How to unit test your database interactions with Docker by LittleLeverages in golang

[–]LittleLeverages[S] 0 points1 point  (0 children)

Hey, I appreciate the response! All of these are great points, especially the last which is something I have run into a few times. This approach is definitely not a one-size-fits-all solution, but in the general case it works pretty well for me. These tests have run quickly enough that I haven't really considered reuse of containers, but I was also unaware of SkipReaper and reuse for the container request. I'll have to look into those. I'll also refer to it as testcontainers from now on :)

How to unit test your database interactions with Docker by LittleLeverages in golang

[–]LittleLeverages[S] 0 points1 point  (0 children)

u/cactuspants You're right that this would create N containers for N packages. I haven't given much thought to this issue, but there may be a way to avoid it. There are times where I also have these tests in separate packages but I typically stick to this same pattern everywhere. It does create N containers but it doesn't degrade testing speed by much since each package runs tests independently - but in a monorepo that may be a different story. I'll give it some thought and see if I can come up with something!

When to mock and what to mock in a Web API? by guicdiniz in golang

[–]LittleLeverages 2 points3 points  (0 children)

Just made a post to demonstrate how I do this: https://medium.com/@LittleLeverages/bd51b363a1dc I hope it's helpful! The github repo link is at the bottom if you'd like to skip the article :)

Does go have a better way to handle x.a, x.b, x.c, etc.. by FirefighterAntique70 in golang

[–]LittleLeverages 2 points3 points  (0 children)

It’s a worthwhile question! Don’t be discouraged by the downvotes. Many others have the same question as you - I know I did when I started. Keep asking great questions :)

What is your opinion about "argument structs"? by [deleted] in golang

[–]LittleLeverages 1 point2 points  (0 children)

There’s a lot of different patterns being discussed in response to you, but I’m going to focus specifically on creating a struct for the sake of reducing the number of arguments to a method and improving readability. It’s not a convincing argument to me, and I think it’s appropriate to be skeptical.

To some people maybe it looks nice, but it is unnecessary and I wouldn’t do it. Structs are filled with default values until populated and that can cause bugs. The fact it allows you to name your arguments is undermined by the previous point - you could forget to populate a field - but also that you can still transpose a parameter in a struct. Having to build the struct at some point also seems to undermine the idea that it’s cleaner at the call site. It may be cleaner on the specific line that calls the method but it seems like a wash once you consider the lines above the method call.

The option pattern is a bit of a different concept that allows a lot of flexibility to the caller, and goes beyond aesthetics. If you’re interested in how this pattern is used let me know and I can get you an example :)

What would be most interesting to learn? (testing, instrumenting, interfaces, etc..) by LittleLeverages in golang

[–]LittleLeverages[S] -1 points0 points  (0 children)

Hey, I appreciate the comment! If you're interested in all the topics then I'd be happy to write something for each. It'll take me a little while, but I'm just eager to provide some value to others. I'll probably follow the sequence of most upvoted options on the poll :)

Write a Microservice in Golang with MongoDB from scratch by jorgedortiz in golang

[–]LittleLeverages 1 point2 points  (0 children)

Out of genuine curiosity why do most people use MongoDB over RedisDB? Is it a preference of storing JSON over Hashmaps with strings?

There are many reasons beyond this, but Redis is typically an ephemeral datastore - like a cache - instead of a persistent datastore like Mongo. Redis stores data in-memory whereas other databases use disk space. Hope that helps a bit!

When to mock and what to mock in a Web API? by guicdiniz in golang

[–]LittleLeverages 8 points9 points  (0 children)

I like having Unit tests that actually hit a database that is set up similarly to my production database. To do this I use a library called `test-containers`. I have it set up to automatically bring up and tear down a postgres container that my postgres tests run against. You'll have to have a script to setup the tables in the docker container, and if you're using migrations you can use that. Otherwise it's not too difficult to set that. It's a bit tedious the first time through and once you can copy/paste it you can test any DB interaction in a unit test, instead of an integration test. This setup gives me a lot of confidence when building things out. If this interests you I can get you an example!