3 ms·
my principal argument against using step functions is that it couples what it is ultimately business logic (your state machine) to a non-programming language th
by ledauphin 5y ago
my principal argument against using step functions is that it couples what it is ultimately business logic (your state machine) to a non-programming language that has no test framework other than E2E integration testing.
I'm legitimately interested in being talked out of this objection, since I think the visualization component is where programming is headed in the long term. Any takers?
- davidkpiano 5y agoSure; this isn't directed at step functions, but in general, if you have your business logic (state machine) in a declarative format, albeit non-programming language (e.g., JSON), then that can potentially make it even more testable than a hand-written, informally-specified state machine in code. Since all of the states/transitions are consistently and declaratively specified, you can iterate through them, build up a directed graph in code, and unit/integration/E2E test them however you'd like. Without that strict declarative "DSL", you would need to figure that out otherwise (requires much more effort), and you're bound to miss coverage on states/transitions, especially if the logic changes.
- ledauphin 5y agothis is exactly the response I was hoping for. in my case, I do still have much better tooling for dealing with state-machines-as-code. but it's a helpful reminder that the tooling for step functions, if I had the time to build it, could potentially be significantly simpler since it would be dealing with a smaller set of possibilities.