Whats worse than TestDrivenDevelopement?

Starting TDD once a 15K LoC project has well started...

sooo.... here I am testing the entirity of clinl ;_;

If a project isn't TDD, there's no point in trying to make the tests afterwards. That's missing the whole point.

You can do TDD on legacy projects. Sometimes it's not the point of having test suite that can test the whole app but the point is that TDD leads you to better code design.

@filthyranter we wanted to start doing TDD and we have to first cover the rest of the code

@TheKarlo95

CLINL. IS. NOT. A. LEGACY. PROJECT

CINALP!!!

btw: clinl.org help us if you have got time to ;)

There are no usable tests in my three (legacy) projects at work. Their cumulative sloc count is, without exaggeration, about the length of War and Peace. Much of the code is also hopelessly poor.

I cannot upgrade dependencies because random things break, and without a test suite I cannot tell what.

It's an impending disaster.

What’s worse? Trying to bring it into a project when you already surpass 2 million lines 😞
The effort involved now to refactor virtually everything to be able to be made TDD semi friendly is very off putting.

@C0D4 Agreed.

@C0D4 ouch!

@gnulinuxer4fun i guess that your approach is wrong. TDD requires you to know what are you coding, have an idea about interfaces and data structures.
Make tests when you need them. If there is a scenario that often gives a problem or is hard to check manually - then write the tests.
In my app I have proper unit tests for like less than a half of the application. The test integration tests checking that correct data flows to lower layers and comes back. In the past we had many issues with external data being somehow not exactly compatible with source changes, or gone. So I decided to use live, real pre/production data. I could because data access is read-only :) now, when tests fail, it means that production fails too. It fails right now.

If I could give you one advice - it would be: make tests when you need them for the new code (fixing bugs =new code) and cover the rest with larger integration (or functional/acceptance/regression) tests, and automate them.

Ask how games are tested :) and how are tested programs that use machine learning. After all, their biggest source of the problems are coming from the data (i classify neural nets/random forests/regression as data, in the end they are weights and numbers not code), something developer can't control. Your - from stuff you can't control - hardware and external code.

Oh, I have a legacy project, data processing app. No tests. Wrote two after implementing a ticket. Code coverage skyrocketed but i'm certain that only one feature will work, unless the source data format changes.

@mt3o thats some good advice. I'll do that!