4 ms·
Sure; 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 lan
by davidkpiano 5y ago
Sure; 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.