Hacker News Reader

Comment by mifeng | Hacker News Reader

Thank you for succinctly summarizing all my frustrations with Solidity. I am developing a fairly complex smart contract (i.e. not a crowdsale) and it's fucking painful. Trivial computations that would take less than an hour to do in any other language take days to implement correctly.

Debugging is also a nightmare. There's no way to step through function calls or set break points, even though it's basically just Javascript. Multiple classes of bugs will generate the same "invalid opcode" error that is only visible at run-time with no indication of what line even triggered the error.

This is why I invested in the Tezos crowdsale. Smart contracts are a great idea but there's gotta be a better way.

View on HN

How do you create unit tests for Solidity code? This would eliminate much of the need for a debugger while also leading to safer code

Unit tests do help, and they are relatively easy in Truffle, the most used JS framework for Solidity. I guess I need to move to more of a TDD style than I'm used to.

In fact the tolling around Solidity and smart contracts is quite rich. It's possible to write unit tests, execute contracts code on a private chain in a similar way to integration/API tests, and measure the code coverage.

Sadly, it's not a common practice to develop contracts with full use of such tooling. See [0] for an analysis of the recent 2017 ICOs and their use of the tooling in crowdsale contracts. A few gems exist, that do quite thorough testing including a CI approach.

[0] https://medium.com/@bocytko/would-you-trust-your-money-to-a-...

I cannot say enough good things about TDD, but YMMV. I also don't stick to it always... it's just that when I take the time to, my code clearly ends up better. I would imagine it's even MORE beneficial in code that deals with a money...

I find it hard to write tests when I'm still formulating the logic of how a problem should be solved. For money-based logic in Solidity, I now like to model it in MS Excel first, write code afterwards, and then finally tests.

> I find it hard to write tests when I'm still formulating the logic of how a problem should be solved

I think everyone does. I certainly do. But pushing through that actually helps your designing, because you start thinking of things in terms of how the API will look, how each building block leading to the final computation will look, and the need to be able to unit-test it as you go forces you to write smaller, more tightly-focused components automatically, which ends up making more maintainable code that is easier to reason about

Reply on news.ycombinator.com