5
Why using Sepolia when you can deploy on L2s instead
11h • albi.eth •

One can argue that by paying fees you can do whatever you want and this is, ofc, very true. But on the other hand I believe that, as developers, we should be mindful on how we use shared resources. Just because something is cheap doesn't mean we should go for it. If I have a contract I want to test, something that is not ready for production, I don't use a production network because I don't want to bloat it with data that doesn't need to be stored forever. Plus, each transaction triggers more CPU time and storage usage on third party services that index the data. Moreover, if a contract interacts with real assets it can expose users that are testing it to potential losses. I don't held accountable anyone who is doing that, as I said before it's permissionless so pay your fees and we are gold. But I think we should have (at least I want to have it for myself) some professional deontology. What's your take on this my dear kiwis?
One reason why I tend to ship straight to production on Ethereum is because the tooling for shipping to a test network is quite bad. E.g., if I want to tie my app into a third party ecosystem it's usually every hard to simulate the production conditions on a test net. Or let me say like this, for the past four years it was like that. From Austin's website (https://austingriffith.com/): > I work for the Ethereum Foundation focusing on developer onboarding, mentoring, and tooling. Btw. what does he know that we don't know? Is his call here the official recommendation of the Ethereum foundation? Anyways, to follow up on how I develop using production: For Kiwi News we have a Zora contract that manages our NFT. But this contract isn't available on any test network and so I'd have to mock it which would cost me way more in development time than if I spend the money to just test in production. So I use forge to write unit tests and also some integration tests. I can then fork with forge to create a copy of the current mainnet with my monkey patched environment. I basically haven't had much of a need for a test net because of that process.
> if I want to tie my app into a third party ecosystem it's usually every hard to simulate the production conditions on a test net That's a fair concern, but so far I didn't have much trouble using the testnet deployments of the protocols I depend upon (YMMV). I can argue that relying too much on prod to check if something works or not isn't a good practice, even tho forking a prod net is definitely a good idea, plus it gives you the superpower to impersonate an account. In general, I try to test things as much as possible in a local node, mocking and/or deploying contracts I depend upon, or automate my tests to work on a fork of a prod network.
> I can argue that relying too much on prod to check if something works or not isn't a good practice Why not? My intuition is that when you test on prod then you know it's working. I have often made the experience that if I deploy to a simulated prod environment like staging then I tend to get false confidence about something that should work on prod, but actually doesn't because staging and prod didn't turn out to be equal in invariants. > In general, I try to test things as much as possible in a local node, mocking and/or deploying contracts I depend upon, or automate my tests to work on a fork of a prod network. What do you use to develop smart contracts? Bc I use forge, maybe the tools afford a certain work flow