This is a classic example of tight coupling, which you should avoid.
Eric Elliott

Too many assumptions about my code. Let me just show it.

async function uploadFile({user, folder, file}) {
const dbUser = await this.readUser(user);
const folderInfo = await this.getFolderInfo(folder);
if (await this.haveWriteAccess({dbUser, folderInfo})) {
return await this.uploadToFolder({dbUser, folderInfo, file});
} else {
throw boom.forbidden("No write access to that folder");
  1. It’s backend. There is no Redux.
  2. It’s already promises composed together.
  3. Nothing is tight coupled because everything is replaceable.
  4. This is only 9 lines of code. Single piece of logic. Breaking this apart will significantly reduce readability.
  5. Integration tests are impossible because: (1) the uploadToFolder can cost up to 9 cents, (2) the getFolderInfo talks to a microservice which is impossible to make available on CI, (3) readUser talks to a Cassandra DB, which is hard to run on a CI.
  6. The functions readUser and getFolderInfo can throw, by design. So, the execution might never get to the haveWriteAccess.

You say “and compose them together again in the context of your app”. That function above is exactly the pieces composed together in the context of my app. I feels like you are saying, “you should test pieces independently, except when you compose them together”.

Please, tell me how to UNIT test my function WITHOUT MOCKS and make sure it is still readable? I’m eager to learn.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.