Skip to content

Arch Forum 2026-09-24

Participants: Backend devs, Kyle and Victor

Agenda

  • Platform news
  • FluentAssertions & Moq replacements
  • Code Reviews Discussion

Summary

Platform news

FluentAssertions & Moq replacements

We need to replace our usage of the two libraries FluentAssertions and Moq. Very likely we will also need to do something about Polly in the future. Details at https://dariusz-wozniak.github.io/fossed/

FluentAssertions

The options are:

  1. Go with MSTest Asserts.
    • No 3rd party dependency needed.
    • Since its MS its highly unlikely it will get rug-pulled.
    • Agents write all the tests anyway, so it doesnt matter if the code is slightly more verbose.
  2. Move to AwesomeAssertions
    • More or less a drop in replacement
  3. Other libraries
    • Too much work for the benefit?

Moq

The options are:

  1. NSubstitute
    • The biggest most establieshed competitor to Moq.
  2. FakeItEasy
    • While smaller than NSubstitute, still well established.
    • Closer to Moq (But does it matter when an agent rewrites?)
  3. TUnit.Mocks
    • Source generated, promises more performance and
    • Less established package
    • Opens door to explore TUnit instead of MSTest in the future for faster tests

Meeting comments & outcome on both:
- No strong opinions on any of these libraries.
- While we dont write tests anymore, the readability of the code actually more important nowadays. Therefor whatever option needs to consider readability.
- NSubstitues is the clear candidate for Moq. We will go with it.
- FluentAssertions is more divided, but since there is a community drop-in replacement thats probably the way to go for now.

Code Reviews Discussion

Discussion around Human code reviews. Meeting comments in italic.

What is the purpose of our Code reviews in your eyes?

  1. Why do we have code reviews? What should they achieve? Catching bugs. Even simple looking PRs might have bad side effects. Difficult to know beforehand what changes are "safe". Goot to share/spread knowledge of changes in the team

  2. Where do human reviews add the most value today? Any recent examples?

  3. Where do they add little value, or fail to achieve what we expect?

How much effort do we put in Code Reviews?

  1. How much time do you spend waiting for code review? Normally its fast enough, not a big deal.

  2. How much time do you spend on code reviews total during last week? It varies. Some think they now spend the same as before, some even less time, and others now spend more time on code reviews than before (as a result of them now having more time to do so)

  3. How much time do you spend on 1 code review. Not that long.

  4. What makes reviews easy or difficult? Difficult to answer, but one thing that can be difficult to handle are AI comments

  5. What things do you look at, what dont you dont look at? (code, PR description, linear ticket, commits, checkout code etc)? Most of the time PR title and the code is enough. Devs often have context from standups/meetings. Based on experience we look at specific things, like quick skim of the tests to see they are on the right level (since AI often does it wrong)

  6. What do you think of PRs from outside backend (bonus question suggested by Gowtham) When non-backend people do PRs its much more work to handle them. AI does not write very good PRs unless guided by an experienced dev.

What could code reviews look like in the future?

  1. What changes needs a (human) code review, what changes do not? Specific thing do not need a review. I.e. document generator and braze templates, localization strings, stage configuration. Also changing existing prod config. However, these PRs are also very quick and easy to review. Config changes can have unintended effects, so still good to review.

  2. Do someone else than the author always need to look at all code before it goes to prod? (e.g. at min 2 people) At least one backend dev should look at all changes (e.g. a PR from non-dev needs a dev review, a dev PR might not)

  3. Do you think we should continue to have them? Yes

  4. If we want to skip (human) code review, when can we do that, and what do we need to do instead? A good side effect of reviews is that other devs know about the change. If we instead do something like a review meeting after the PR is already merged, then its too late.

Overall the feeling is that at least for now code reviews works well, and the devs do not feel swamped in PR Code Reviews.