
The Action Pattern: Clean, Obvious, Testable Code - feross
https://ponyfoo.com/articles/action-pattern-clean-obvious-testable-code
======
externalreality
I think the article was nice. I really would have liked a more concrete
definition of the pattern and earlier in the article. I think the most
important part of the article for me was:

1) Centralize all of our calls to other code in one place. 2) Share response
values from each step with other steps. 3) Clearly delineate the order of
steps in our code. 4) Make our code more maintainable and extensible by
avoiding nested spaghetti code.

I think test code should be the clearest, easiest, most lucid code. Even at
the expense of code that in other contexts may be considered boilerplate or
redundant. Test code serves a different purpose than production code and is
made to be rapidly modified, quickly and dirtily refactored, and very easy to
understand, and to be exceedingly clear as to what cases it is actually
performing a run-time test on. Often I see authors writing test code as if the
test code itself is built to be maintained and reused. In some cases that is
true but generally not when actively developing a system.

~~~
Gibbon1
The reason this works is he's limiting the amount of working state to the
minimum needed to accomplish his actions/tasks at each point in the process.

