Subclasing and overriding is not a good idea. There is no compilation failure if you forget to override a function which can lead to flakey tests at best and prod data impact at worst.
Credentials should only be provided at the application root, which is going to be a different root for a test harness.
Mockito shouldn't change whether or not this is possible; the code shouldn't have the prod creds (or any external resource references) hard coded in the compiled bytecode.
I totally agree, I’m being tongue in cheek, but given how poor some codebases can be, the more precautions the better ie compilation failures on non-mocked functions.
What’s your plan for when you no longer own your custom domain (think bus factor)? Someone else register your domain and now has access to all your accounts.
Everyone has their own risk profiles, mine assumes I retain control over my domains and emails. I prepay for them several months in advance to make sure I don't lose ownership. any service provider worth their salt will have a human factor for customer support who can help you if any such issues show up.
Thank you for expanding. Sure you can prepay up to a certain extent. Eventually your domain will be available to others for purchase and therefore your accounts will become vulnerable. Maybe this isn’t an issue if in the worst situation you’re not around but if this could cause chaos for your friends and family I would suggest taking it into account.
Given that domain renewals can be purchased multiple years into the future, along with the fact that there are grace periods after expiration, it would take an awful lot of failure to lose a domain unintentionally. I've held my primary domain since 1997 multiple registrars and numerous hosting / colocation arrangements over the years. It sounds harder than it is if you haven't done it before.
OP is likely talking about local business logic, ie password field is min 3 chars long. You validate that in the FE before sending it up to get instant feedback to the user (yes you also have it on the server).
OP is likely talking about local business logic, ie password field is min 3 chars long. You validate that in the FE before sending it up to get instant feedback to the user.
There are external factors apart from your own API that can impact latency, for example a user could be in an area of poor internet connection or have a slow connection. Users do not live in our perfect development environment bubble where everything just works, it’s important not to assume that.
That's how we got to "download 50 GB before playing a game on a console is fine", feels like we just stopped carying. Sending the form to the BE just to do same basic validation adds so much latency to the UI that it feel unusable for many/most users.
Related: A few Sundays ago I wanted to play Anno again. Sadly it was not installed on the Laptop I used. So i started downloding it because you won't get it on DVD/as iso-file today). Now it's a few Sundays after and I didn't play yet - because the download took 7 hours.
That's such a ridiculous logical falacy. You already have to send the form input to submit the form in the first place and you already need server side validation.
I just checked one of my app's register page (which makes > $2M ARR). If you submit a short password it returns an error from the backend that says "Password should be at least 6 characters.". (It uses Supabase). But yeah, that is so unusable it is basically the same as taking 7 hours to download a game onto your Playstation. Great logic!