Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Follow the wormhole through a path of communities !webdev@programming.dev
This only checks that functions are called in the right order. Not that the functions are doing the right thing or if the functions are called with the correct arguments. Quite pointless testing IMO.
For example, it won’t capture cases where cmdChargeCreditCard returns a payment ID that exists for cmdCompleteOrder to use.
Set up an in-memory database, or test against a real database. You don’t test side effects by pretending that the side effects are correct.
You can still test the functions individually or run the entire flow against a test database, but without an effect system like this, it's very hard to test business logic in isolation.
However, I think it’s safe to say this architecture is effectively AI-native.
Lol...at first I thought the article wasn't satire until I found the AI part. Well done.
Summary: Hey, let's add another abstraction layer so we don't need to mock these calls, but we don't test what happends in that pesky database call, because we would need to mock that somehow. But now we need AI to handle the abstraction layer.
I think I'll use this article as a basis for discussion for job interviews.
Thanks.
Integration tests against a real database can and should still be performed. The idea here is the ability to test business logic in isolation without using mocks. Effect systems also have other benefits. You basically get cross-cutting concerns like logging and profiling for free. Every single database call, API request, and file read in your entire application can be easily logged and profiled.
I am not arguing against an effect system. They can help in certain circumstances. But none of the reasons in the article are one of them. Also the article is a bit lopsided because the real pain with these systems is error handling, resource handling like transactions or parallelism etc.
What you write about the "other benefits" profiling and logging is also not the reason to introduce such a system.
What does an api request has to do with business logic?
It feels a bit as if you just discovered the idea of effect systems and are now trying to justify to use it no matter what. 😉
I think you might be focusing on the execution of the request rather than the orchestration. The decision of when and why to make an API request is absolutely business logic. In imperative code, that logic is hard-coded to the execution. By separating the intent from the execution, we can test that decision flow without spinning up the infrastructure.
