There's like 1500 TLDs, now some of them are restricted and country-code TLDs but now it makes me wonder how much it would actual cost per year to maintain registration of every non-restricted TLD. I'm sure theres some SaaS company that'll do it.
OTOH, doesn't ICANN already sometimes restrict who has access to a given TLD? Would it really be that crazy for them to say "maybe we shouldn't let registrars sell npm.<TLD> regardless of the TLD", and likewise for a couple dozen of the most obvious targets (google., amazon., etc.)? No one needs to pay for these domains if no one is selling them in the first place. I don't love the idea of special treatment for giant companies in terms of domains, but we're already kind of there with the whole process they did when initially allowing companies to compete for exclusive access to TLDs, so we might as well use that process for something actually useful (unlike, say, letting companies apply for exclusive ownership of ".music" and have a whole legal process to determine that maybe that isn't actually beneficial for the internet as whole: https://en.wikipedia.org/wiki/.music)
>maybe we shouldn't let registrars sell npm.<TLD> regardless of the TLD
Cool, get big enough, become friends with the right people and you can squat an entire name on the internet. What, you're the Nepalese Party for Marxists, you've existed for 70 years and you want to buy npm.np ? Nope, tough luck, some random dude pushes shitty javascript packages over there. Sorry for the existing npm.org address too, we're going to expropriate the National Association of Pastoral Musicians. Dare I remind you that the whole left-pad situation was because Kik, the company, stole (with NPM's assistance because they were big enough and friends with the right people) the kik package ?
At least they're paying dozens of millions to buy a shitty ass .google that noone cares about because more and more browsers are hiding the URL bar. I'm glad ICANN can use it to buy drinks, hookers instead of being useful.
> Dare I remind you that the whole left-pad situation was because Kik, the company, stole (with NPM's assistance because they were big enough and friends with the right people) the kik package ?
> Cool, get big enough, become friends with the right people and you can squat an entire name on the internet. What, you're the Nepalese Party for Marxists, you've existed for 70 years and you want to buy npm.np ?
I think you and I have drastically different ideas about how dramatic a response is warranted by the scenario of needing to buy a domain with a different three letters or maybe even four or more letters before the TLD.
> Dare I remind you that the whole left-pad situation was because Kik, the company, stole (with NPM's assistance because they were big enough and friends with the right people) the kik package ?
...and then the package was entirely removed, which would have been preventable by sane policies around making removal just not allow new dependencies to use it. You're also conflating a resource that's ostensibly free and perpetual for people to claim with one that's only rented for fixed periods of time for money.
Its not expensive for them, its expensive for their customers. If you went over your spending limit and they deleted all your shit, people would be absolutely apoplectic. Instead they make you file a relatively painless ticket and explain why you accidentally went over what you wanted to spend. This is an engineering trade-off they made to make things less painful for their customers.
There is a huge difference between deleting data and stopping running services.
You're right in that there's a few services that expose this complexity directly, the ones where you're paying for actual storage, but this is just complex, not impossible.
For one thing, storage costs are almost always static for the period, they don't scale to infinite in the same way.
If it’s a web server, sure. But if you drop data because you’re no longer processing it, or you need to do an expensive backfill on an ETL, then turning off compute is effectively the same as deleting data
Why would I apoplectic at Amazon if I set “turn my shit off after it has accrued $10 in charges” to TRUE and they actually followed what I asked them to do?
Is it a serious question? Because then I could have you shutdown just by posting a call to ddos with a link to your search form on an anime image board.
OK? Good! That's what I want to happen! I want that. I do not care if some weirdos on an anime image board can't access some image. I don't want my credit card maxed out.
Is that not a serious request? I play around in the same big-boy cloud as some SaaS company, but I'm on the free tier and I explicitly do not want it to scale up forever, and I explicitly do not want to destroy my credit or even think about having to call Amazon over a $100,000 bill because I set my shit up wrong or whatever. I want it to shut off my EC2 instance once it has used up whatever amount of resources is equal to $X.
Obviously any world with this feature would also feature customizable restrictions, options, decision trees, etc etc. I don't think anyone is or was suggesting that someone's SaaS app just gets turned off without their permission.
They could add it as an optional limit. If it's on and is exceeded, stop everything. Surely the geniuses at Amazon (no they really are, I'm not joking) can handle it.
What about the space you're using? Do they delete it? Remove all your configurations? Prevent you from doing anything with your account until you up your limit or wait until your month resets?
If you're worried about getting a big bill, and you don't care if it gets shut off when you're not using it, why don't you shut it down yourself?
AWS made the tradeoff to keep the lights on for customers and if there is a huge bill run up unintentionally and you contact them with it they refund it. I've never experienced them not doing this when I've run up five figure bills because of a misconfiguration I didn't understand. I don't think I've ever even heard of them not refunding someone who asked them for a refund in good faith.
How many times has AWS refunded you a five figure bill? I've heard stories from people who got refunded but were told that it would be the first and last time they would get a refund.
I think I'm up to two five figure bills and two six figure bills refunded for various companies/clients. On one account, we had about $70k refunded, then a year or two later $130k. The normal monthly spend was closer to $30k.
There were no warnings or "don't do it again". They, very reasonably IMO, asked us to essentially explain how and why this happened and how we'd stop it happening again. They then provided some additional guidance and resources around those areas. In the one case where the charges were due to compromised credentials, they asked us to rotate all of our access keys before they issued the refund.
Completely anecdotal and slightly dated information, but that's been my experience.
I think one of the reasons I appreciate AWS so much is that any time there has been snafu that led to a huge bill like this they've made it pretty painless to get a refund- just like you experienced.
If it is a "free tier", Amazon should halt the application when it exceeds quota. Moving the account to a paid tier and charging $100k is not the right thing to do.
Yes. They said it was free then they surprise charge you $100k.
That’s an insane amount of both money and stress. You’re at Amazon’s mercy if they will or will not refund it. And while this is in process you’re wondering if your entire financial future is ruined.
I have never in 8 years of being in the AWS ecosystem and reading forums and Reddits on the internet had anyone report that AWS wouldn’t refund their money.
If you go over your budget with AWS, what should AWS do automatically? Delete your objects from S3? Terminate your databases and EC2 instances? Besides, billing data collection doesn’t happen anywhere near realtime, consider it a fire hose of streaming data that is captured asynchronously.
At Amazon scale, including a "we don't delete the data for 30 days if a bill isn't paid" clause is a plausible thing to include in the "free" tier. Paid tiers owe Amazon the contracted rate for the storage, as with any similar contract, and when Amazon deletes the data if payment isn't rendered when due is up to the terms of the contract.
There is no such thing as the “free tier” at least until July of this year. Some services are free for the first year up to a certain limit, some give you a bucket of free usage every month, etc.
Then you owe the contracted rate for the storage. These massive bills are almost never for storage, they're almost always for some sort of compute or transport left unrestricted. If you store 500TB you'll get an $11k/month bill, but the vast majority of the services can simply cut off usage at a limit. Even storage could prevent adding new data if you hit a pre-specified limit, so you'd only pay for the data you already had.
If I know my service should never use more than 1TB total I'd like to be able to set a limit at (say) 2TB total with warnings at 0.6TB & 1TB, thus limiting spend to $46/month on storage. Sure, my service will fail if I hit the limit, but if it's using double the storage I expect it to use something went wrong & I want to require manual action to resolve it instead of allowing it to leak storage unbounded.
This is not a particularly difficult problem to make significant improvements on. There are some edge cases (there always are) but even if spending limits were only implemented for non-storage services it'd still be better for customers than the status quo.
Provide the user the tools to make these choices. Give the option to explicitly choose how durable to extreme traffic you want to be. Have the free tier default to "not very durable"
Bam, you said. They’d do it if they cared, but they don’t and prefer the status quo. 100k surprise bill is the type of thing people kill themselves over. Horrific
You mean like having a billing alert send an event that allows you to trigger custom actions to turn things off? That already exists. It has for years.
> How is AWS suppose to know whether you want to immediately scale or not?
Ask? This is not some impossible problem.
Yes, there is a UX challenge to be solved.
But also, doing so is well within the capabilities of a company like Amazon.
They simply have no incentive to help out since there is less money to be made by making it easier to spend less money. And, purely capitalistically, if you have to pick between a potential bug or misconfiguration that causes extra spending you can walk back with customer support, and a bug or misconfiguration that results in extra downtime for your 7+ figure customers, you pick the latter.
I agree, but I could also see how someone would complain about that: “Our e-commerce site was taken down by Amazon right on our biggest day of the year. They should have just moved us up to the next tier.”
Seems like the most flexible option is to put a spending limit in place by default and make it obvious that it can affect availability of the service if the limit is reached.
My credit cards have credit limits, so it makes sense that a variable cost service should easily be able to support a spending limit too.
You're misunderstanding the offering. (Maybe that's their fault for using intentionally misleading language... but using that language in this way is pretty common nowadays, so this is important to understand.)
For a postpaid service with usage-based billing, there are no separate "free" and "paid" plans (= what you're clearly thinking of when you're saying "tiers" here.)
The "free tier" of these services, is a set of per-usage-SKU monthly usage credit bonuses, that are set up in such a way that if you are using reasonable "just testing" amounts of resources, your bill for the month will be credited down to $0.
And yes, this does mean that even when you're paying for some AWS services, you're still benefitting from the "free tier" for any service whose usage isn't exceeding those free-tier limits. That's why it's a [per-SKU usage] tier, rather than a "plan."
If you're familiar with electricity providers telling you that you're about to hit a "step-up rate" for your electricity usage for the month — that's exactly the same type of usage tier system. Except theirs goes [cheap usage] -> [expensive usage], whereas IaaS providers' tiers go [free usage] -> [costed usage].
> Amazon should halt the application when it exceeds quota.
There is no easy way to do this in a distributed system (which is why IaaS services don't even try; and why their billing dashboards are always these weird detached things that surface billing only in monthly statements and coarse-grained charts, with no visibility into the raw usage numbers.)
There's a lot of inherent complexity of converting "usage" into "billable usage." It involves not just muxing usage credit-spend together, but also classifying spend from each system into a SKU [where the appropriate bucket for the same usage can change over time]; and then a lot of lookups into various control-plane systems to figure out whether any bounded or continuous discounts and credits should be applied to each SKU.
And that means that this conversion process can't happen in the services themselves. It needs to be a separate process pushed out to some specific billing system.
Usually, this means that the services that generate billable usage are just asynchronously pushing out "usage-credit spend events" into something like a log or message queue; and then a billing system is, asynchronously, sucking these up and crunching through them to emit/checkpoint "SKU billing events" against an invoice object tied to a billing account.
Due to all of the extra steps involved in this pipeline, the cumulative usage that an IaaS knows about for a given billing account (i.e. can fire a webhook when one of those billing events hits an MQ topic) might be something like 5 minutes out-of-date of the actual incoming usage-credit-spend.
Which means that, by the time any "trigger" to shut down your application because it exceeded a "quota" went through, your application would have already spent 5 minutes more of credits.
And again, for a large, heavily-loaded application — the kind these services are designed around — that extra five minutes of usage could correspond to millions of dollars of extra spend.
Which is, obviously, unacceptable from a customer perspective. No customer would accept a "quota system" that says you're in a free plan, yet charges you, because you accrued an extra 5 minutes of usage beyond the free plan's limits before the quota could "kick in."
But nor would the IaaS itself just be willing to eat that bill for the actual underlying costs of serving that extra 5 minutes of traffic, because that traffic could very well have an underlying cost of "millions of dollars."
So instead they just say "no, we won't implement a data-plane billable-usage-quota feature; if you want it, you can either implement it yourself [since your L7 app can observe its usage 'live' much better than our infra can] or, more idiomatically to our infra, you can ensure that any development project is configured with appropriate sandboxing + other protections to never get into a situation where any resource could exceed its the free-tier-credited usage in the first place."
Yes and no. Yes, if we're just specifically talking about the ability to support a free trial that will never bill you (i.e. what the OP was talking about); but no, if we're talking about the more-general ability to set spending limits and never be billed for overage (what this subthread drifted into discussing.)
Oracle Cloud has a 30-day free trial; and that free trial seems to have had some dedicated effort put into a whole divergent billing-infra path for it.
Under Oracle Cloud's free trial, you get a certain amount of spend ($300 in credits); and then, when your trial either expires (30 days) or you run that credit pool down to zero, your account is shut off.
Oracle do eat any marginal costs from your spend taking your credits "below zero" before they shut the account off, because your account was never billing to you anyway; it was billing to Oracle's marketing department as a lead-gen expense.
In other words, unlike Oracle Cloud's steady-state IaaS offering, their free-trial IaaS offering is actually a prepaid (but usage-billed) paradigm — with Oracle being the ones doing the pre-payment.
This works much like an oldschool prepaid phone plan, where you pay in every month to be given a certain number of [expiring/non-"rollover"] minutes/texts/MB of data; and then you get an itemized invoice at the end of the month for how close you came to "using up" each resource that month. And you very well can use up a resource's monthly paid allocation before the end of the month — e.g. "running out of texts" and being unable to send more, rather than those converting into something billed to you. (In a prepaid context, that "converting into being billed" is called "flex" or "pay-as-you-go" [PAYG] billing, and is usually some extra option you would have to enable, if offered at all.)
At scale, prepaid usage-billed systems are also asynchronous; to continue the telecom analogy, most phone-service providers won't re-aggregate your prepaid calling minutes to notice you've run out, until you hang up your current call. Only rarely do they have infra where the billing system can ping the telecom switches' control planes to say "hey, this guy just went over, hang up the call" — and when they do, they only do such checks on a 5-minute/30-minute interval, probably as a scheduled batch query.
But, yes, prepaid systems almost always do just eat any overage generated by this detection gap. This is usually safe, because prepaid systems are almost never elastic to the point that you could accrue nontrivial expenses during that short accounting gap.
When a system is that elastic, a systems architect responds by saying "this should be a postpaid system."
Which means that Oracle Cloud's free trial — insofar as it allows you to make use of truly-elastic resources with per-credit upstream basis costs, like FaaS compute — is probably vulnerable/exploitable. Oracle may sometimes be eating some hefty bills, where people on a free trial have wired their FaaS into a proxy fronting some already-highly-popular service.
This is mostly fine, if you have Oracle's treasury, because you'll still be doing KYC in advance of giving out these trials, so you'll only be letting any given individual do one trial.
But this does put Oracle in the territory of "having to think about people who buy burner identities on the black market [usually for ~$1] to sign up for services using them" + "having to think about people who sign up for their free trial and then sell that free-trial account's credentials on the black market [again, usually for ~$1]."
I haven't checked myself, but I would guess that like any other provider who sees this type of attack (e.g. Hetzner), Oracle Cloud likely has hardened registration flows that reject identities + cards from certain parts of the world; traffic fingerprinting heuristics that immediately shut down free trials if they start up a DDoS attack or the like; etc.
Which is something the other clouds get to skip thinking about entirely, by not having a true "free trial" with a prepaid model, and instead just offering e.g. a one-time $300 sign-up-bonus account credit.
---
But remember, we're only talking about the "free trial" here — something you only get access to for the first 30 days.
Oracle's free tier — the thing you have after the first 30 days — is no different than the one every other IaaS offers. It needs a billing account populated by your credit card; there's infrastructure to allow you to automate control-plane actions in response to billing thresholds being hit, but no offering that will wire anything up for you; etc.
In Oracle Cloud's free tier, you can set budget limits that will prevent new costed resources from being leased while your account is over that limit in a given month (which is certainly nice) — but those budget limits don't affect ongoing usage-based-billing of a resource. Your FaaS endpoints will continue to accrue vCPU-seconds of billed usage, until you — or some automation you wrote — shuts them off.
Really? You’re not “disputing it”. You were charged fair and square. You send an email to their customer support and they say “no problem” and help you prevent it in the future.
And what if they don't say "no problem"? Like the Netlify case where they at first offered a reduced bill (which was still a lot) before the post got viral and the CEO stepped in.
Amazon is currently permissive which splits opposition, this won’t always be the case, they will tighten the screws eventually as they have done in the past in other areas. Amazon because it’s so broadly used undermines the utility of chargebacks, you can do it but it’ll be a real hassle to not be able to use Amazon for shopping. A lot of people will just eat the costs, is Amazon knows this they will force the situation more often because it’ll make them more money.
Putting stuff on the internet is dangerous, but the absence of hard caps is a choice and it just looks like another massive tech company optimizing for their own benefit. Another example of this is smartphone games for children, it's easier for a child to spend $2,000 then it is for a parent to enforce a $20/month spending limit.
Yes, you as a developer should know something about how the service works before you use it. I first opened the AWS console in 2016 and by then I had read about the possible gotchas.
You do know that large corporations and startups employ junior devs as well, right?
All else being equal, would you rather choose the platform where a junior dev can accidentally incur a $1M bill (which would already bankrupt early startups), or the platform where that same junior dev get a "usage limits exceeded - click here to upgrade" email?
Well, first I wouldn’t give a junior dev with no experience admin rights to an AWS account and would I have tight guardrails around what they can do - like I’ve done now with over a dozen implementations for clients since I’ve been in consulting for five years and the four years before that as an architect for product companies.
I also wouldn’t give a junior dev access to production databases.
Also from working with AWS from both the inside (Professional Services) and the outside at a third party consulting companies, I know how aggressively AWS is about keeping startups and they would never risk losing the continuing revenue of a company like that.
> All else being equal, would you rather choose the platform where a junior dev can accidentally incur a $1M bill
If a junior dev has the access to do that, then there is a big failure (probably more than one) by someone who isn't a junior dev after choosing AWS that was necessary to enable that.
As the saying goes, when you owe the bank $100 you've got a problem, when you owe the bank $100k the bank has a problem...
On serverless, I can enter numbers in a calculator and guess that running my little toy demo app on AWS will cost between $1 and $100. Getting hit with a huge $1000 bill and a refusal to refund the charges (and revocation of my Prime account and a lifetime ban from AWS and cancellation of any other services I might otherwise run there) would be totally possible, but I have zero control over that. Expecting to go on social media begging for a refund is not a plan, it's evidence of a broken system - kinda like those "heartwarming" posts about poor people starting a GoFundMe so their child can afford cancer treatment. No, that's awful, can we just be sensible instead?
If a server would have cost me $20 at a VPS provider to keep a machine online 24/7 that was at 1% utilization most of the time and was terribly laggy or crashed when it went viral, that's what $20 buys you.
But, you say, analysis of acttual traffic says that serverless would only cost me $10 including scaling for the spike, in which case that's a fantastic deal. Half price! Or maybe it would be $100, 5x the price. I have no way of knowing in advance.
> (and revocation of my Prime account and a lifetime ban from AWS and cancellation of any other services I might otherwise run there)
Also a vital lesson from the big tech companies that sell a wide variety of services: don't get your cloud hosting from a company that you also use other services from.
I had to disable photo syncing because Google photos eats up my Gmail space. Having Amazon's cloud billing fuckup threaten your TV access is another level.
We clearly need to keep the option open to burn those bridges.
In any case, if I ever host anything, I'm going to host it from my home.
You haven’t been able to use your Amazon retail account to open an AWS account for years. You don’t “beg”. You just send them an email and they say “yes”.
I have never in 9 years working with AWS - four at product companies as the architect, 3.5 at AWS itself working in the Professional Services department and the last two working at 3rd party companies - ever heard or read about anyone either on a personal project or a large organization not be able to get a refund or in the case of a large org, sometimes a credit from AWS when they made a mistake that was costly to them.
From your bragging one could tell that you have seen _a lot_ of charging mistakes and "happy" refund stories from AWS. It's scary that a single human can do extensive statistics on personal experience about these monetary horror stories, don't you think?
I assume you have seen many casual instances of cost overrun in that time. I'm sure you've also seen instances where an extra $10k flies out the door to AWS and people think "no big deal, that one was on us." This world doesn't have to exist. Even if AWS has a policy of always refunding people for a big oopsie, the fact that you have seen so many big ones suggests that you have also seen a lot of little ones.
By the way, there is nothing stopping AWS from reversing their trend of issuing refunds for big mistakes. "It hasn't happened in the past" isn't a great way to argue "it won't happen in the future."
Sure. The issues with AWS could all be solved with decent billing software, though. 15 years in there isn't a good excuse for this state of the world except that it's profitable.
You can set up billing alerts to trigger actions that stop things when they trigger. The easiest way is to take permissions away from the roles you create.
They give you the tools. It’s up to you to use them. If that’s too difficult, use the AWS LightSail services where you are charged a fixed price and you don’t have to worry about overages or the new free tier
Because despite what everyone here is saying, before July of this year, there was no such thing as a free tier of AWS, there was a free tier of some of their services
Both of these are about an account compromise, which is a really fascinating story about incentives. An accidental overrun on something you designed on AWS indicates you are hooked on their drugs, so obviously the dealer is happy to give you another free hit after you had a bad trip. That's good marketing. An account compromise has no intention, so giving you a refund is just a waste.
Must be really nice people there which don't want any money. Really warms my heart.
ofc. When things go viral they say "yes". But i would really love to get some number how many students and hobbiests got a 1k-2k bill and just paid it for the problem to go away.
Amazon is a publicly traded company. If they wave fees every time something goes wrong, investors would tell them something.
AWS and all of the other cloud providers gives millions in credits each year for migrations and professional services for both their inside professional services department and third party vendors. The reputational risk for them to go after some poor student isn’t worth it to them. The same is true for Azure and GCP.
Have you read one even anecdotal case where AWS didn’t immediately give a refund to a student who made a mistake just by them asking?
What would the would “tier” mean here? There is a US tax bracket (tier) where no tax is due on long-term capital gains. That doesn’t mean it’s wrong when I pay long-term capital gains.
There's an expectation when it comes to consumer goods, and even protection in most jurisdictions, that you can't simply charge someone for something they don't want. It's like dropping a Mercedes at someone's house then charging them for it when they never wanted or asked for it. Allowing a "free" tier to run up so much traffic that it becomes a $100k bill is ridiculous and probably illegal.
Taxes are different because they never exceed the amount the person paying the taxes receives.
Indeed, if you keep your usage within the tier of usage that is free, they charge you exactly $0 per month. It is only for usage beyond that free tier that you are charged.
I agree that there should be an option for a user to select "I never want to pay so much as $0.01 and if there is a circumstance where I'd need to, I expect you to shut off my services and delete my data if needed in order to avoid me incurring any bills."
That would solve this issue, but needs to be an explicit opt-in, because a lot of users don't want that.
You are a bit naive. They are making a ton of money with this dark pattern. As others have said Free-to-100K is not in the most generous realm of expectations. Its also why they have been doing the refunds as long as AWS has been a thing. They know it will not hold up in court. Not a month goes by without some HN story about something like this post.
They do this and make it easy to get a refund because for every demo account that does it some bigger account accidentally gets billed 10K and they have to pay for it. They have skin in the game and cannot risk their account being down for any time period.
Counter real world example. I was doing some consult work for a place that had a 9k unexpected charge on AWS. They asked about it and I explained about how they could dispute it. They said ugh never-mind and just paid it. FYI it was a charity which I've since learned its common for charities to be wasteful like this with money since they are understaffed and OPM(Other peoples money)
So how is that a counter example? The client never asked for a credit. Since the startup I worked for, I have been working in AWS consulting - first directly at AWS (Professional Services) and now a third party consulting company.
While I have no love for AWS as an employer, I can tell you that everyone up and down the chain makes damn sure that customers don’t waste money on AWS. We were always incentivized to find the lowest cost option that met their needs. AWS definitely doesn’t want customers to have a bad experience or to get the reputation that it’s hard to get a refund when you make a mistake.
Of course AWS wanted more workloads on their system.
Semi related, AWS will gladly throw credits at customers to pay for the cost of migrations and for both inside and outside professional services firms to do proof of concepts.
You, but shorter: It can't be done perfectly in 100.0% of all possible circumstances, so better to do absolutely nothing at all. On an unrelated note, this strongly aligns with their economic interests.
For storage specifically, in that circumstance, if you weren't hellbent on claiming otherwise: it's easy to figure out what to do. For storage: block writes and reach out to the customer. Also, people are extremely unlikely to accidentally upload eg 250tb which is how you'd get to, say, $200/day. Whereas similar bills are extremely easy to accidentally create with other services.
It's totally reasonable to want spend limits firmer than AWS' discretion, which they can revoke at any point in time for any reason.
Once I've been kidnapped by a guy who also happen to run a security business. After a bit of discussion, I was about to convince some of his sbire to release me without paying the ransom. I'm so glad they did accept that, and I never fail to use and recommend the services of the security business now.
Parameterized tests are good, but I think he might be talking about exercising all the corner cases in the logic of your function, which to my knowledge almost no languages can auto-generate for but LLMs can sorta-ish figure it out.
We are talking about basic computing for CRUD apps. When you start needing to rely upon "sorta-ish" to describe the efficacy or a tool for such a straightforward and deterministic use case, it may be an indicator you need to rethink your approach.
If you want to discount a tool that may save you an immense amount of time because you might have to help it along the fast few feet, thats up to you.
If you can share a tool that can analyze a function and create a test for all corner cases in a popular language, I'm sure some people would be interested in that.
Maybe you should have brought that up earlier instead of acting smug and burying the lede? It's also pretty telling that you didn't elaborate this further and kept your comment short.
What you should have said is that some parameterized test generators do automated white box testing where they look at your code similar to a fuzzer and try to find the test cases automatically. Your first link is literally just setting up an array with test cases, which basically means you'd have to use an LLM to quickly produce the test cases anyway, which makes parameterized testing sound exceedingly pathetic.
>IntelliTest explores your .NET code to generate test data and a suite of unit tests. For every statement in the code, a test input is generated that will execute that statement. A case analysis is performed for every conditional branch in the code. For example, if statements, assertions, and all operations that can throw exceptions are analyzed. This analysis is used to generate test data for a parameterized unit test for each of your methods, creating unit tests with high code coverage. Think of it as smart fuzz testing that trims down the inputs and test cases to what executes all your logic branches and checks for exceptions.
> Maybe you should have brought that up earlier instead of acting smug and burying the lede? It's also pretty telling that you didn't elaborate this further and kept your comment short.
I thought people were generally competent within the areas they discuss and are aware of the tooling within their preferred ecosystem. I apologize if that is not the case.
Interactive debuggers and printf() are both completely valid and have separate use-cases with some overlap. If you're trying to use, or trying to get people to use, exclusively one, you've got some things to think about.
I almost exclusively debug via printf / logging, and I am so stupendously ignorant that I have even written and published a multi-platform interactive debugger, to go with the compiler I also wrote (one of several, but this one was the most successful). Make of that what you will, I suppose.
It helped me cut back on my drinking significantly. I'm not an every day drinker but a weekend binge drinker and the amount I drink when I drink is down by I'd estimate by around half or more.
reply