And yes, if we're being pedantic, an AML system would need unit and integration tests—but the question is whether or not tests as a whole are useful. So unless you're arguing that an AML system can be made so simple that no tests are required and it "fits in your head," let's agree that testing has its place.
Not in my experience. Overengineering and unit-testing always come hand in hand, likely because both are the "enterprise" way of doing things.
> the question is whether or not tests as a whole are useful
Huh? Nobody ever asked this question.
Questions I'm always debating are:
1. Whether unit tests are useful (no in 99% of cases)
2. Whether more tests = better (no)
3. Whether you should invest in automated testing before manual becomes painful (no)
> unless you're arguing that an AML system can be made so simple that no tests are required and it "fits in your head,"
Some tests will be required. But yes, it should fit in your head, otherwise you cannot reason about it. Building AML system that you can't reason about is a road to failure.
It doesn't mean that you need to load implementation of every single rule in your head. But you need to fit, for example, the idea of rule engine and the constraints of rules working together. If you build rules that can do anything with no constraints (depend on each other, override each other), then you're screwed.
> introduce layers of abstraction, try increasingly complicated View/Model architectures
> you can come up with clever ways to make the rules of your AML policy composable and easy to change
These are the exact design decisions that are typically accompanied by unit tests.