4 ms·
I feel that if most of your tests relies on mocks it is a symptom of a very side-effected programming style. If you cannot unit test most your business logic th
by snorremd 3y ago
I feel that if most of your tests relies on mocks it is a symptom of a very side-effected programming style. If you cannot unit test most your business logic then you are probably mixing up your business level code with side-effecting code (like calling APIs or DBs).
Personally I've found it better to split pure business logic and side-effecting logic as close to the edge (API endpoint handler) as possible. Then it is trivial to see where side-effects happen and you get to easily write unit tests for the business logic that matter.
Mocking is mostly always a pain and I would rather not mock at all and do proper end-to-end for integration code if possible.
- wickoff 3y agoIf your database isn't involved in your business logic then you're probably significantly underutilizing capabilities of modern databases.
- krubar 3y agoHow is that so?
- ehutch79 3y agoFor SQL databases at least: You can your db sum columns faster than you can grab the data, parse it, and compute the sum. In query calculations to avoid race conditions from doing the math on separate servers, etc. Triggers and procedures are a thing. The nosql/kv store hype missed a lot of stuff relational/sql dbs did well. Mostly because at the time they declared sql was too hard, or just never studied anything.
- nly 3y agoThe 'business logic' for many apps consists entirely of calling other APIs and databases.
- sumedh 3y ago> business level code with side-effecting code (like calling APIs or DBs). Sometimes the business logic is in DBs with stored procs.
- joeblubaugh 3y agoThat’s a whole other can of worms! The difficulty of versioning stored procedures is such a detriment to effectively using all that power.
- ehutch79 3y agoThey should be part of your migrations? and your migration should be versioned?