Comment by renaudpawlak | Hacker News Reader

Comment by renaudpawlak | Hacker News Reader

Parent Full thread

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-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, platform, with examples: https://plaform.dlite.io).

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.

I think you’re assuming people are incapable of determining scope on their own, just like you’re assuming that programmatic testing is a magic bullet for finding software regressions / bugs. Both assumptions are wrong.

You are aware that there is such a thing as a Pontiac and such a thing as a Mercedes, right? One is better than the other. Costs more, too. That doesn’t mean there isn’t a place for both to exist. That doesn’t mean the lesser one is trying to be the more expensive one and failing.

> I think you’re assuming people are incapable of determining scope on their own, just like you’re assuming that programmatic testing is a magic bullet for finding software regressions / bugs.

You are arguing against a straw man, as I don't assume either of those things. Testing a magic bullet? Ludicrous.

> You are aware that there is such a thing as a Pontiac and such a thing as a Mercedes, right?

Hmm, but both a Pontiac and a Mercedes present the same driving interface.

I would instead compare No Code to DIY tools for (pick your industry: music production, graphic design, etc). I agree that you can go very far and do amazing things with DIY.

> don't scale past a certain level of complexity

I'd say that's a given, both that they're not very complex and not intended to scale past a few users.

> tend to fall apart as they become successful.

There are lots of definitions of success. A dashboard on a phone app so that the boss can see the green lights on his servers is successful. It gave him what he wanted: green lights on his phone.

> By and large the target market for No Code doesn't value testing.

This seems to be your qualifier of why they aren't 'good'. I don't own one, or work for one, or even subscribe to a platform that makes them, I'm just a passer-by here, but I can see the value in them. The only one I have used is open source (NodeRed).

When there's no time and you need to glue two or three API's together in 30 minutes, I see nothing wrong with them. It goes without saying that the result will be fragile and only for a handful of people, probably only one of which will get write access.

Here's my use case: co-founded a disaster relief non-profit in 2017 (hurricanes). Our window of opportunity to do good deeds was about 3-4 days, by then the red cross and fema trucks would arrive. When we need to process data it's probably a job with a roughly $0.00 budget and needs to be done in 30-45 minutes, then there's something else to do.

For that? They are wonderful. I built a phone bar-code scanner that could pull price data from Kroger's API to account for food donations in about an hour and a half. Can anyone else do that writing code by hand? I say no, the UI alone would take longer (however rudimentary that UI is). Was it tested? Yeah, a quick manual once-over and me face-to-face telling the person admining it that if the bar code didn't read just google it and plug the price in by hand, or don't and we'll do it later if that isn't feasible due to volume. We were just trying to do a slightly better job than a pencil and a clipboard could do, not a perfect one.

Reply on news.ycombinator.com