3 ms·

I fail to see how unit tests are going to help. If rules are independent, overall complexity is low, even if there are thousands of rules. If rules are dependen

by hbrn 4y ago

I fail to see how unit tests are going to help. If rules are independent, overall complexity is low, even if there are thousands of rules. If rules are dependent, unit tests are useless. > 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.

turnsout 4y ago
Those are the design decisions accompanied by developers who think complexity is the enemy and seek to "contain" it at all costs—even when it adds hierarchical/organizational complexity. 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.
- hbrn 4y ago
  > Those are the design decisions accompanied by developers who think complexity is the enemy and seek to "contain" it at all costs—even when it adds hierarchical/organizational complexity. 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 before you make any change. But you need to fit, for example, the idea of rule engine and enforce constraints on 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. You're going to be playing whack-a-mole with your tests, and while it will feel productive, it's a death sentence.

by hbrn 4y ago

turnsout 4y ago

Those are the design decisions accompanied by developers who think complexity is the enemy and seek to "contain" it at all costs—even when it adds hierarchical/organizational complexity. 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.

hbrn 4y ago
> Those are the design decisions accompanied by developers who think complexity is the enemy and seek to "contain" it at all costs—even when it adds hierarchical/organizational complexity. 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 before you make any change. But you need to fit, for example, the idea of rule engine and enforce constraints on 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. You're going to be playing whack-a-mole with your tests, and while it will feel productive, it's a death sentence.