Testing in no-code





Testing in no-code
By Aron Korenblit • Issue #25 • View online
The last issue had broken links due to an oversight on my part. I deeply apologize for that and will try my best to double check from here on out.
A note on timing, I’m going to commit to publishing this newsletter and host livestreams every 2 weeks! Both will drop on Wednesdays with the newsletter coming in the morning and the livestream at 5PM EST.
Today, I’ll be showing off 5 cool things you can do with the new Airtable button field including searching the web using, sending Zapier webhook’s, sending email reminders and create receipts.
On to the update:

I’d like to posit a new law that is as you include more no-code tools in your tweet, the odds of me receiving it increase proportionally. Case in point, someone shared this fantastic tweet with me from the founder of Actiondesk (note: haven’t used the tool) and it sparked all kinds of thinking
Jonathan Parisot
Is there a testing tool for no code solutions?
- We have many reasonably complex workflows using @airtable, @zapier, @SlackHQ , @mailshake
- When changing something in Airtable for ex, I want to make sure I don't break sth

@bentossell @makerpad @_Contournement any thoughts?
This is absolutely an issue.
I’ve found myself in so many workflows thinking, am I going to break something if I click here? Or is this stitch of tools going to output what I expect it to? How do I ‘test’ whether it does without risking a run?
More personally, if you’ve been an Automate All the Things subscriber for long enough, you may remember the time where I sent you and everyone on the mailing list a ‘test’ email. Every day. For a week. I still cringe thinking about it.
As no-code tools multiply, the problem is only getting worst.
Here’s folks showing off their ‘complex’ Integromat workflows, most with 100+ steps.
What’s the largest Integromat scenario? Over 800 modules. Couldn’t even fit it in a whole screenshot. 😂

Are we proud? Unbelievably, so.

Craziest thing? It's not the only one this big.🤯

Did we mention, it was still created without coding? https://t.co/r4C7oqU8de
Testing in no-code?
Testing in no-code seems to mean broadly three things:
1- Can these tools support the desired workflow? Can I do what I want to do?
2- How will the workflow handle errors?
3- How do we provide visibility to folks in our tools that they may be triggering workflows?
#1 - Can I do what I want to do?
When it comes to whether something is possible without code, we have to check whether our glue – Zapier, Integromat etc. – supports the different actions & triggers we need. Zapier probably does the best job of this with their app directory.
There really is no other way than being intimately familiar with the tools you’re using to know whether a workflow is possible using no-code.
I’d love for an entrepreneur to create a draw.io type diagram creator that depending on the tools you want to connect and the expected workflow, tells you whether it’s possible. That said, like many of you I’m sure, my workflows are rarely so complex from the get go that I can’t just give it a try.
#2 - How will the workflow handle errors?
Out of the three, I think mainstream no-code tools perform best here. Zapier will automatically notify you when Zap breaks and offers granular settings for when to be notified.
Beyond that, Integromat has error handling built in so you can fork your workflow based on the error itself.
Parabola isn’t great and breaks when any API it’s working with throws an error. They’re aware that it’s an issue and I’ll definitely keep annoying them until they have better error handling!
Just like #1, handling errors more gracefully is an opportunity for entrepreneurs! Take Chris Spags from Jetboost which builds add-on features (Boosts) to Webflow. Their next Boost will replicate something you could do with Zapier (with a lot of difficulty) but at a much cheaper price point (why pay for Zapier if all you need is one flow?). And his Boost will handle Webflow specific errors gracefully! The effort for Zapier to handle Webflow errors gracefully in every case isn’t important enough for them to prioritize which means an opportunity for folks like Chris.
Chris Spags 🎾
Your Webflow Zaps that update live items will fail under some scenarios:

- Site has multiple domains published at different times
- Staging collection schema has been modified since last publish
- Webflow API rate limit hit

Imagine if your no-code tools handled these for you 😉
#3 - How do we provide visibility in our tools that they’re triggering automations?
Personally, I think this is the biggest issue!
I’ve become more and more reliant on multiple tools working together to get my workflow done. For me, it’s usually a change in Airtable being synced with multiple 3rd party. As I update information in my Airtable base, Zapier’s new record in view trigger will cascade that change into multiple third parties automatically (set to publish in Airtable -> send to Webflow).
If a new collaborator comes into my Airtable base, they have absolutely no visibility into what workflows are triggered when. Hell, I sometimes inadvertently trigger workflows from my own base without realizing it!
The only available remedy is good documentation. It could be emojis in view descriptions or field descriptions letting collaborators know that changing information could trigger a workflow. There is no visibility of tools into each other. Every no-code today stands on its own.
I’m no developer but I would love to see folks build tools that increase visibility across no-code tools. A few ideas to get you started:
  • An Airtable block that automatically surfaces recent Zapier runs or generally shows the different automations connected to a base (could even look like schema block but with Zaps).
  • A way to see third party data directly from Airtable/Webflow. Select a record or CMS item and see additional information about that user/item in 3rd parties (e.g. see this user’s conversations in Zendesk or this item’s shipping status) directly in my interface without having to sync between the systems.
In all cases, although we’ve integrated many tools, we’re not quite at the point where we can understand what’s going on outside of the tool we’re in.
That said, the only thing stopping us from being better at testing is building the tools we need!
PS if you’re interested in building on top of Airtable, we’ve just released our beta SDK so you can build your own block. We’ve also hosted a Blocks contest with 100K in prizes and will release the winners shortly :)
Did you enjoy this issue?
Aron Korenblit

Weekly thoughts on the working smarter not harder using no-code tools + a weekly Airtable tip. Written by Aron Korenblit

In order to unsubscribe, click here.
If you were forwarded this newsletter and you like it, you can subscribe here.
Powered by Revue