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