dockertest VS micro

I am using https://github.com/ory/dockertest for tests, specifically for databases. Is there any advantage to use Testcontainers?

Now, let's run the tests. For this purpose, we are going to use dockertest, but test containers is also a good solution.

During my path learning go so far I have come across some amazing libraries and utilites, one of my favourite for integration testing is dockertest.

Things I can't live without in a new Go project in no particular order:

- https://github.com/golangci/golangci-lint - meta-linter

- https://goreleaser.com - automate release workflows

- https://magefile.org - build tool that can version your tools

- https://github.com/ory/dockertest/v3 - run containers for e2e testing

- https://github.com/ecordell/optgen - generate functional options

- https://golang.org/x/tools/cmd/stringer - generate String()

- https://mvdan.cc/gofumpt - stricter gofmt

- https://github.com/stretchr/testify - test assertion library

- https://github.com/rs/zerolog - logging

- https://github.com/spf13/cobra - CLI framework

FWIW, I just lifted all the tools we use for https://github.com/authzed/spicedb

We've also written some custom linters that might be useful for other folks: https://github.com/authzed/spicedb/tree/main/tools/analyzers

I've used dockertest a bunch and it is really amazing.

Reminds me of https://github.com/ory/dockertest

If your project is relatively simple and you can get away with recreating your scenarios against a real mock database and run other related services locally. It would be good to setup docker containers for your test scripts and write e2e tests. I believe e2e tests are harder but more useful in understanding/reasoning how users are impacted.

Just a heads up, the repository in your comment is invalid, the correct link is https://github.com/ory/dockertest

Don't mock. Use https://github.com/ory/dockertest to actually run tests against a dockerized DB.

Use a library like ory/dockertest to spin up a test database for integration tests. It's easy to use, and tests are still fast. It'll take a minute to download the mysql docker image the first time. But, once it's been downloaded, starting the db, running migrations, and running the tests is still pretty quick.

Hi HN

I'm Asim, an engineer and author of the open source project Micro (https://micro.dev). I've been on this forum in various forms since 2009. In that time I've seen a lot of shifts in the technology landscape, participated in a few and even tried to start a company myself (which ended up VC funded). In typical HN fashion, I drank the kool-aid and applied to YC around 8-10 times. I got so far as going to mountain view for an interview but never got in. I played right into the idea of starting a fast growing company and "changing the world" by solving my own problems in the developer ecosystem but somewhere along the way lost sight of the problem I was solving. I think it speaks to my own need to seek validation (in the wrong place) but also the general nature of the ecosystem that became all about the pursuit of more funding, growth, users, etc. It really feels like while there's 70-80% value created, the other 20-30% is doing us a lot of harm. Consumer software has become addictive, corporations are becoming huge profit seeking blackholes that mostly cater to their shareholders and we have yet to see any great alternative to the existing tools and services we're now beholden too.

A couple weeks ago I posted Micro Chat (https://micro.mu) on HN - https://news.ycombinator.com/item?id=36135683. This was my first effort in trying to solve the problems mentioned above. But I don't think it's enough. I think what we're talking about is something much bigger. And it's not going to be solved by open source, federation or a single tool. I'm starting to think we need to build something bigger, an entirely new community led app platform.

So here's my idea. Mu (pronounced mew) is a proposal to build a new community app platform from the ground up. It would address all the problems we seem to mention here about ownership of services, addictive scrolling, profit seeking agendas and do it by empowering a community to crowdfund the creation of an alternative system that focuses on being a utility for the people. It would generally be open source, potentially self hostable, but the larger goal would be to empower a handful of people to host and run the service for everyone else, a built like how Let's Encrypt is run today.

I've thrown this idea around a lot, started many discussions here and even tried to push a few things out but never really gotten anywhere with it. I think part of it is to just, build the smallest piece and see where it goes, hence Micro Chat, but the other part is to gauge the sentiment in the room and see whether we can actually fund something much bigger totally aligned with the community. I'm a huge fan of Google services and the utility they offer, but the nature of technology has veered so far into addiction with scrolling feeds, streaming and social media that I feel there's a need to do something now.

If there's interest, please comment and provide feedback.

Cheers

Hey all

I'm Asim. I'm an engineer who's been hacking on an open source project called Micro for the past eight years (https://micro.dev). In that time I've done a lot of things, all Dev related but ultimately most of my career was spent working on platforms for consumer products. After many attempts I've decided the path forward is to focus on building something that solves my own problem. Micro Chat is a solution to some of the social media problems I've been having.

What I've been looking for most of my life is a community. A place to belong. I scoured the internet for that with strangers. But I think that's wrong. The public forums are also the wrong place to find that connection. What we need to do is focus on smaller communities starting with real connections. We need to strip away a lot of the addictive behaviours and issues created by social media. I think things like hackernews are great because it's very simple text based, with no notification and centers around conversations about topics of interest. I think that's how group chat should also be. The difference here is, I want a place to build small private communities e.g micro communities. Most real groups lose their value beyond a certain size. For me that's around 20 people. As an introvert I really care about strong connections with a handful of people. Unfortunately those real world connections are now spread globally as people moved away and while we have private slacks or WhatsApp grojps to stay in touch it just feels like the wrong setup for that. If anything I want to consolidate it into one place.

Anyway I'm sharing this now to get some feedback. I think the tech and the product will evolve but only by finding out if others feel the same.

https://micro.mu

Happy to help anyone starting up. I raised a couple mil in seed funding for an open source project after bootstrapping for a few years. I'm sure the YC crew would be more helpful but I got rejected by YC like 8 times and took the direct route to funding.

We built this https://M3O.com. It was based on this https://github.com/micro/micro

Just happy to help given my own tough experiences. Pitch deck reviews, intros, etc.

Had similar goals. Started by writing Go interfaces for it with Go Micro - https://go-micro.dev then opted for the platform service model as you mentioned with Micro - https://micro.dev

I think whether it's Dapr, Micro or something else, the platform service model with well defined interfaces is the way to go. I don't think a lot of people get this yet so it's still going to be a few years before it takes off.

What if any is the relationship between https://m3o.com/ and https://micro.dev/ ?

I shared this post in a few developer communities like Hacker News and it was well received. Over the past few years I've been working on an open source project called Micro, an API first development platform and I'm now sharing Micro Services, a catalog of reusable real world Micro services.