Working at a company with no automated tests. There’s not even a collection of regression tests or anything to follow. I was wondering if anyone could share or point me towards a good template to start building out test cases as a first step?
I think this is something you’re gonna have to just jump into and start since you don’t have anything to work off of. it’s going to take a lot of work, but at least you’ll be able to work off your own ATFs once you finish. good luck…
I mean, start with trivial cases of the core functionality of what your system does. Then build upon it based on your own findings and what your clients report.
E.g. if your system loads images then put in a tiny 5x5px solid square or checkerboard pattern and see if it loads. Then try putting multiple images, different formats (webp, gif, png, tga) etc. see if that breaks anything, keep building out.
It probably really depends on the project, though I’d probably try and start with the tests that are easiest/nicest to write and those which will be most useful. Look for complex logic that is also quite self-contained.
That will probably help to convince others of the value of tests if they aren’t onboard already.
if there are zero automated tests, things probably weren’t written with (automated) testing in mind, so there may be a lot of coupling… starting off with integration tests just to validate existing behavior is a good start. hopefully the existing applications aren’t also inextricably bound to environments that are run on pet servers and managed by other teams…
The one I hate? Your unit tests pass when run locally, and in your sandbox environment, and in dev, and in UAT, but prod? Fuck that, failing with reckless abandon.
I recently spent about two weeks trying to figure out why an intercontinental connection between two of our sites was broken. Not really my job, I just care about application level, but the network guys were beyond useless.
In the end I had the problem isolated to a specific network segment in India, which made them look at the right system and fix things. The reason? “We put up a firewall the day your problems started which blocks everything, if we allow your connection it works”.
After many years (10+), I finally find a company that actually, really, implements CI/CD. Then I look at the tests and it’s actually the most inane shit imaginable, tacked on top of ancient existing code, not maintained. I spent more time fixing the stupid tests than actually fixing the bugs I was tasked fixing. Amazing.
I can’t really imagine working on any code base that has to actually be maintained and doesn’t have tests. The amount of times that tests have safed my ass at my job are uncountable
And it’s number 1 priority for management to employ as few developers as possible and stretch their team as thinly as possible. Hence still no unit tests in any of the companies I’ve worked at recently, despite everyone knowing they’re worth it, including lip service from management. They just won’t invest in testing, no matter what. One company even fired all the testers then complained to the developers that the product was getting less reliable.
We test the shit out of our Apis. We do more API level/integration testing though.
I.e. a test will be something like “if the db is in this state, and we hit this endpoint with these params, does it return what we expect and update the db correctly”.
Our app is primarily about users maintaining stuff on big datasets with complicated aggregation and approval logic. So setting up a scenario and checking the app does what the business logic says it will do is what we want to know.
It makes refactoring wayyyyy less painful to just know that the app will always behave itself. Rather than testing whether a function can add 1 + 2 correctly, we can test each endpoint does what it’s supposed to do.
It gives us loads of confidence that the backend is doing what it’s supposed to. If you do a huge refactor you don’t need to worry about whether you broke the test or if the test is failing correctly. If the tests all pass everything is working as it should.
Downside is longer test execution times (because a temporary db needs set up) when running the full suite. Worth the trade off for us though.
I actually had to refactor configuration module some time ago. These really came in handy. But was it worth it? Well… it saved some time, the time that could be used to debug problems manually, but it made me a lot more confident that the functionality that worked before, worked after.
The ones I have seen so far are probably written by the same people who don’t understand the usefulness of comments, I reckon. And maintained with the same enthusiasm.
@Zeragamba@QuazarOmega just because something is paranoia doesn't mean it isn't true. Whenever I turn on the DuckDuckGo "VPN" to stop tracking by third party apps, I'm amazed at how many request are happening from apps I hardly use and many I don't expect (though I should know that something can still be open source Free Software and that the open code contains surveillance capitalsm tracking in order to fund the project)
This meme is really only true for things like Slack where the app is just the webpage in an app, and even then it's not quite true because Electron is a lot heavier than a webpage because it has to now run the webpage and the app - which I think is terrible.
But then also, Electron enables actual apps to be developed using web standards - which I think is great.
TLDR: Use Electron to make apps, not glorified webpages.
For Slack it does. Building an app via Electron means it’s cross-platform by default, so Slack doesn’t need to invest in separate platform teams to solve the same problem (Windows, macOS, Linux).
Electron also has better support for things like native notifications, video and voice calls, offline capabilities, and to other native APIs etc that are either unsupported or spottily supported via the browser.
It’s a much more lightweight option for building cross platfrom apps than Electron. Heck, even Tauri is better than Electron even though it also uses web technologies for UI.
It has all this support for native platforms yet it’s always a clunky memory hog that makes zero effort to respect the design language of the OS it’s running on.
I’m on macOS, I want the app to be a native macOS app. If I wanted it to look like a webpage, or Windows, or Linux GTK then I’d switch to one of those and expect it to match those paradigms.
It has all this support for native platforms yet it’s always a clunky memory hog
Maybe so but it has improved a lot over time. The app devs share some responsibility too so it’s not all on Electron.
zero effort to respect the design language of the OS it’s running on.
That’s the Dev’s design choice, not a limitation of Electron.
I’m on macOS, I want the app to be a native macOS app. If I wanted it to look like a webpage, or Windows, or Linux GTK then I’d switch to one of those and expect it to match those paradigms.
I don’t disagree but at the end of the day it doesn’t matter to enough people for it to become an issue. People are used to Slack and the way it works.
Moreover the cost of building the same app 2x or 3x simply doesn’t make business sense.
I’m a web developer but is there no concept of classes, libraries, etc in other programming languages?
What happened to writing the “core” of an app that doesn’t rely on UI then simply writing the front ends for each platform you want to support?
You keep saying Electron is used for better compatibility and listing out Linux, Windows, macOS but here’s the thing — most companies are only targeting those. That’s just three (if you don’t write for a million desktops on Linux).
Is it really so hard to support just three environments with only the UI being tailored for the OS it’s running on?
Honestly, it just feels like poor tooling and a poor excuse.
What happened to writing the “core” of an app that doesn’t rely on UI then simply writing the front ends for each platform you want to support?
What do you mean? I can’t speak for Slack but I’m sure some degree of business logic / client side logic separation exists.
By the way, what you just described is the essence of cross-platform development, rather than an argument for building apps natively.
simply writing the front ends for each platform you want to support?
But why would you rewrite the “front-end” for each platform if you have one you could just port over? Who is going to pay for those 2x developers and what would be the ROI on this effort?
That’s just three (if you don’t write for a million desktops on Linux).
Is it really so hard to support just three environments with only the UI being tailored for the OS it’s running on?
In Slack’s case I’d wager the answer to be a resounding YES. I don’t think you fully grasp the full scope Slack’s capabilities, and the amount of work involved to build native clients for not just one or two, but three different platforms - it’s definitely not just the “UI”.
Honestly, it just feels like poor tooling and a poor excuse.
Quite the opposite - frameworks like Electron let’s devs with your skillset build with the stack you already know, and abstracts away quite a bit of the cross-platform complexities, which strangely enough is what you are suggesting but also what you are arguing against
programmer_humor
Hot
This magazine is from a federated server and may be incomplete. Browse more on the original instance.