Test-driven development

I think test-driven development is only scalable way of writing new software

1 Like

Interesting concept – sounds pretty radical, but likely something you won’t understand until you try it. The following quote resonates:

Limbo scales technical collaboration by propagating tiny changes instantly.

1 Like

another view point on TDD

1 Like

I’ve been transitioning to a more test-driven development flow in that when I develop a feature, I exercise it end-to-end during development using tests. The Simple IoT serial client is an example:

In each test, I’m spinning up the entire SIOT stack. I don’t exhaustively test every function as I feel that just adds an extra code burden to maintain. But if there are complex algorithms in a function, then I test. The same with functionality – I don’t test all functionality either, but I test enough to have a high confidence it’s working, and if I discover a bug, I try to add a test for it. Like security, with testing there has to be a balance. You have to get more out of it than what it costs you to implement and maintain. And code (including tests) is a liability, not an asset. In this case, the iteration time of testing a new feature in a test is much faster than manually exercising it through the UI. The key is to keep your build/deployment mode simple enough that you can spin up the entire app in test. Then there is no real difference between unit and end-to-end tests – the testing framework in your language can implement both.

The NATS project is a good example of this approach.