4 ms·

I would say "none of the No Code platforms I've seen are fine", because all the ones I'm familiar with have either inadequate testing or no testing at all. The

I would say "none of the No Code platforms I've seen are fine", because all the ones I'm familiar with have either inadequate testing or no testing at all. The problem is that apps built without testing don't scale past a certain level of complexity — and so complex projects built with No Code tend to fall apart as they become successful. It's not that it can't be done, but that there's probably very little demand for it. By and large the target market for No Code doesn't value testing. If you know of a No Code platform with good testing support, I'd love to hear about it...

tmcneal 5y ago
We're a no-code platform for testing, if that counts. :) Should work pretty well for testing applications built with no-code tools since the same person who builds the app can also write tests for it. Would love to get your feedback if you do try us: https://reflect.run/ https://reflect.run/
- rectang 5y ago
  I just watched your 6-minute intro video and I love it. It's not what I asked for (it won't help me write tests for the Keap campaign builder, oy), but it fills a different, sorely felt need: showing non-technical people how automated tests are constructed. I can point to this video to say, "this is what I'm doing when I'm writing tests", and I think at least some of them will understand the value proposition. The more savvy ones might buy into your platform or even try constructing tests themselves. Bravo!
  - tmcneal 5y ago
    Wow, thank you!
- Aeolun 5y ago
  15 hours per month for $300? I run a combined 120h/day on AWS for less. Maybe it makes sense for some, and if people pay you for it then that’s great, but to me I cannot see the economics of that ever working out.
  - tmcneal 5y ago
    That's fair - if you compare us to raw compute we are going to be well over an order of magnitude more expensive, even with the volume discounts we offer at our "contact us for pricing" tier. Usually when folks are considering us, they're comparing us to the other alternatives which generally are either (1) have folks on staff do each regression test pass manually, (2) hire additional devs/automation engineers to build a code-based automation suite, or (3) have existing developers spend part of their time building and maintaining a code-based automation suite. When you look at the cost of those alternatives we tend to be pretty competitive. Where we're not a good fit pricing-wise is when someone wants to run very simple tests at a high volume, like running synthetic testing / monitoring scenarios in production, or for load testing.
    - Aeolun 5y ago
      Yeah, fair enough. If it wasn’t me maintaining our pipeline I can see how the value proposition quickly increases. I guess there is a happy point in between too small and too large where you have a bunch of QA, but no dedicated people to keep your pipeline up (and if things like Cypress didn’t exist, it’d be more or less impossible).
renaudpawlak 5y ago
If you use a no-code front-end builder (like Bubble.io), I guess you could use any UI test framework to test your app. It is not the same as unit testing, but it is more global and in the end, UI tests are quite powerful to detect regressions that matter to the users. That said, if you think that unit tests are always required, then I think that you are a victim of code complexity. Let me explain. I do believe that unit testing is good to master complexity, which often becomes out of hands with classical approches because the code is complex by itself (new lib versions popping up all the time, breaking refactoring). The thing with low-code is that it lowers that complexity by proposing more declarative approaches, which are more stable and less broken when changing versions (think of a static web page for instance, you don't really need to test it that bad although the browsers versions bump all the time). I think that it is more important to be able to control complexity in order to avoid testing, rather than having to test "no matter what", like your reaction suggests. Plus, testing implies CI/CD and a lot of automation that are extremely complex to set up and consume a lot of resources. I wrote a blog post about this stand-point lately https://cincheo.com/2021/10/03/when-low-code-meets-local-first-software/ https://cincheo.com/2021/10/03/when-low-code-meets-local-fir... DISCLAIMER: I am currently working on a new low-code platform for frontend development based on the local-first paradigm. (web site: https://www.dlite.io https://www.dlite.io, platform, with examples: https://plaform.dlite.io https://plaform.dlite.io).
- rectang 5y ago
  I deliberately used the nonspecific term "testing" and avoided "unit tests" because arguments about unit testing vs. integration testing vs. ui vs. functional vs. system vs. [...] are generally not productive, and tangential to the point I was making. > I think that it is more important to be able to control complexity in order to avoid testing, I think that's a worthy ideal to strive for, but it's not so easy to control complexity in practice. First, a lot of complexity arises from business logic requirements. Even if you have an "engineering" department, they're going to have limited ability to negotiate away complexity in business concerns. And many outfits who adopt No Code don't have engineering departments, and aren't well versed in engineering principles like simplifying, testing, or even keeping backups, let alone modularization, separation of concerns, loose coupling, or other approaches for managing complexity at scale. And then there's time. It takes time to whittle something down so that it is simple and elegant. That time costs precious resources which small outfits may not be able to spare.
shireboy 5y ago
That would be a really cool approach. Start the project by listing, in plain text, test criteria. Build out the app and tie it back to the test criteria in some meaningful way.

tmcneal 5y ago

We're a no-code platform for testing, if that counts. :) Should work pretty well for testing applications built with no-code tools since the same person who builds the app can also write tests for it. Would love to get your feedback if you do try us: https://reflect.run/ https://reflect.run/

rectang 5y ago
I just watched your 6-minute intro video and I love it. It's not what I asked for (it won't help me write tests for the Keap campaign builder, oy), but it fills a different, sorely felt need: showing non-technical people how automated tests are constructed. I can point to this video to say, "this is what I'm doing when I'm writing tests", and I think at least some of them will understand the value proposition. The more savvy ones might buy into your platform or even try constructing tests themselves. Bravo!
- tmcneal 5y ago
  Wow, thank you!
Aeolun 5y ago
15 hours per month for $300? I run a combined 120h/day on AWS for less. Maybe it makes sense for some, and if people pay you for it then that’s great, but to me I cannot see the economics of that ever working out.
- tmcneal 5y ago
  That's fair - if you compare us to raw compute we are going to be well over an order of magnitude more expensive, even with the volume discounts we offer at our "contact us for pricing" tier. Usually when folks are considering us, they're comparing us to the other alternatives which generally are either (1) have folks on staff do each regression test pass manually, (2) hire additional devs/automation engineers to build a code-based automation suite, or (3) have existing developers spend part of their time building and maintaining a code-based automation suite. When you look at the cost of those alternatives we tend to be pretty competitive. Where we're not a good fit pricing-wise is when someone wants to run very simple tests at a high volume, like running synthetic testing / monitoring scenarios in production, or for load testing.
  - Aeolun 5y ago
    Yeah, fair enough. If it wasn’t me maintaining our pipeline I can see how the value proposition quickly increases. I guess there is a happy point in between too small and too large where you have a bunch of QA, but no dedicated people to keep your pipeline up (and if things like Cypress didn’t exist, it’d be more or less impossible).

renaudpawlak 5y ago

If you use a no-code front-end builder (like Bubble.io), I guess you could use any UI test framework to test your app. It is not the same as unit testing, but it is more global and in the end, UI tests are quite powerful to detect regressions that matter to the users. That said, if you think that unit tests are always required, then I think that you are a victim of code complexity. Let me explain. I do believe that unit testing is good to master complexity, which often becomes out of hands with classical approches because the code is complex by itself (new lib versions popping up all the time, breaking refactoring). The thing with low-code is that it lowers that complexity by proposing more declarative approaches, which are more stable and less broken when changing versions (think of a static web page for instance, you don't really need to test it that bad although the browsers versions bump all the time). I think that it is more important to be able to control complexity in order to avoid testing, rather than having to test "no matter what", like your reaction suggests. Plus, testing implies CI/CD and a lot of automation that are extremely complex to set up and consume a lot of resources. I wrote a blog post about this stand-point lately https://cincheo.com/2021/10/03/when-low-code-meets-local-first-software/ https://cincheo.com/2021/10/03/when-low-code-meets-local-fir... DISCLAIMER: I am currently working on a new low-code platform for frontend development based on the local-first paradigm. (web site: https://www.dlite.io https://www.dlite.io, platform, with examples: https://plaform.dlite.io https://plaform.dlite.io).

rectang 5y ago
I deliberately used the nonspecific term "testing" and avoided "unit tests" because arguments about unit testing vs. integration testing vs. ui vs. functional vs. system vs. [...] are generally not productive, and tangential to the point I was making. > I think that it is more important to be able to control complexity in order to avoid testing, I think that's a worthy ideal to strive for, but it's not so easy to control complexity in practice. First, a lot of complexity arises from business logic requirements. Even if you have an "engineering" department, they're going to have limited ability to negotiate away complexity in business concerns. And many outfits who adopt No Code don't have engineering departments, and aren't well versed in engineering principles like simplifying, testing, or even keeping backups, let alone modularization, separation of concerns, loose coupling, or other approaches for managing complexity at scale. And then there's time. It takes time to whittle something down so that it is simple and elegant. That time costs precious resources which small outfits may not be able to spare.

shireboy 5y ago

That would be a really cool approach. Start the project by listing, in plain text, test criteria. Build out the app and tie it back to the test criteria in some meaningful way.