sean
@swabbie.eth
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
5 replies
0 recast
1 reaction
sean
@swabbie.eth
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?
2 replies
0 recast
1 reaction
Matt Solomon
@msolomon.eth
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.
1 reply
0 recast
3 reactions
Matt Solomon
@msolomon.eth
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)
2 replies
0 recast
1 reaction
Matt Solomon
@msolomon.eth
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
2 replies
0 recast
3 reactions
sean
@swabbie.eth
Good points. The arguments I was reading were mainly “to reduce switching costs,” which seemed like a fairly weak argument for a team likely using both anyway.
0 reply
0 recast
0 reaction
