What is the best way to approach TDD on <http://Pipedream.com|Pipedream.com> without mocking up <http://Pipedream.com|Pipedream.com> locally?

This topic was automatically generated from Slack. You can find the original thread here.

Rob Pitt : Heya, I hacked together a system on Pipedream and it works but now I want to make it more complex. This was also an introduction to Node.JS for me and I’m beginning to wish I had created the system with a test-driven development paradigm. I want to now go and add tests to the code to make sure I don’t break anything I’ve done already and create further enhancements in a test driven fashion. A quick Google suggests that Jest is a popular choice for unit testing Node.JS code, but it appears to be a CLI app so I doubt it would work correctly with Pipedream.com.

My question is what is the best way to approach TDD on Pipedream.com without mocking up Pipedream.com locally? Or maybe that would be the best approach? :thinking_face:

Dylan Sather (Pipedream) : we’re working on a way to develop workflows locally that I believe will help a lot with this. Currently, since you have to develop workflows in the Pipedream UI, it’s difficult to take a full TDD approach to test all of the code you’re using within a workflow.

I wanted to mention these options, as well:

• If you develop component actions for use in your workflows, you can manage those on your local machine and publish them to use in your workflow. Since actions are just Node.js code, those can be tested locally.
• You can also develop your own npm package, storing your code there, testing that code locally. Then you can publish that package and require it within your workflows.
Let me know if that helps. Please follow that first issue on local workflow development - we’ll share details on that ticket as we make progress.