Sharding in een ander jasje

I have learnt something new. Sharding in a differnt context. Normally, i would think that would be about databases. You can shard them in any way you prefer to speed up performance. FOr example. sqlite3 has as downside the concurrency, but if you would give each customer it's own sqlite database you would even scale better than any other. That's a kind of sharding, then you hae domain sharding and sharing based on technical properties. Whatever you want. YOu get the point.

But you can do that to tests too I have learnt. I just designed a creative one that is very benefitical. SOmetimes, especially when later wanting to execute it, concurrent testing does not go very well with tests that use data and so on. SO i designed a system where you have two shards: one with tests that contain data, that shard will be executed sequental, the other shard extremely async (fuck 48 playwright browsers at once. but i have 64gb anyway).

But that's very cool. YOu just add a decorator to your tests. That's all. @shard(async=True) (or false).

You can do whatever you want.

I just learnt it from AI. Never seen before. But it's so fucking smart. This proejct has thousand tests so that does matter. DevPlace has 4000 tests (but no sharding yet, will work on it some day, should create ticket. Will ticket be created? YO know, yes. because i copy and paste all this content at once to devii and devii knows what to do. What a time to be alive.