exp. with Foundry recently, and it's cool, but I'm a bit confused as to why testing in Solidity is preferred when it's highly likely interactions w/ your contract will need to use JS/TS anyway.

3P apps call your contract directly via frontend or they have a contract that calls your contract that itself uses a frontend

/bettik founder /outercorps stalwart | ex-binance, ex-celsiusX

wouldn't it be more helpful to everyone to just test in JS/TS so implementation in a frontend is just copy/paste for much of the code?

what am I missing?

1/n Foundry maxi reporting for duty 🫡

I think this framing is wrong: The goal of testing smart contracts is not to make the lives of JS/TS integrators easier, it's to write maximally secure smart contracts.

Security at Optimism. Formerly built Umbra and more at ScopeLift

3/4 Ok why is foundry the best to help write secure contracts?

1. Writing in solidity minimizes context switching between languages
2. Writing in solidity helps you learn solidity and it's edge cases/limitations
3. Comes with a great fuzzer for fuzz/statefulFuzz tests. This is not natively supported in Hardhat/JS/TS

4/4 

4. It's fast. Faster tests and more fuzz tests > more experimenting > more learning > more secure contracts

2/n (Even with the "help integrators" goal there's 4+ mainstream JS ways to call contracts, so your tests may not even help most JS devs depending on which you chose. And for protocols like uniswap lots of activity is bots in rust/go/etc, so JS may not be the best choice for the "help integrators" goal anyway)