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
Varun Srinivasan
@v
Testing code written in one language using another language is a massive kludge (very rare that this happens, except maybe e2e tests) You introduce a lot of complexity at the boundary, translating objects from one language to another and back. That makes it hard to write good tests.
1 reply
0 recast
3 reactions
EulerLagrange.eth
@eulerlagrange.eth
There are many tools that will generate typescript bindings for a contract based on its ABI. The graph outputs a interface you can apply to a ethers Contract. I always add a command in package.json to build the contract typings.
1 reply
0 recast
1 reaction
Beau
@beauwilliams.eth
I think depending on your contract size and complexity and specialisation. I can imagine for a very large codebase working only in solidity one might want foundry. Myself I am very happy with hardhat as I am full stack. But for solidity only Devs, I can imagine the draw.
0 reply
0 recast
1 reaction
TQ
@tylerquinn
Test contract functionality and security in Solidity, test the frontend with js/ts. I’ve done both but once I used Foundry I never wanted to go back to testing my contracts with js
0 reply
0 recast
0 reaction
