Hacker News new | ask | show | jobs
by pc86 2693 days ago
A healthy chunk of that is probably folks who work somewhere where you can't/don't have time to write tests, and keep up with it on their own so they are current when job searching.
2 comments

Or to scratch their "do it right" urge, to have a repo that they can show potential employers, to learn TDD, to learn a new language they can't use at work but hope to use professionally at some point, to have a repo that they can eventually turn into something revenue generating, or because they contribute to open source projects that require it.

I've written tests on personal projects for all of those reasons at one point or another (except the last).

Agreed, I certainly didn't want to learn TDD by doing TDD at work (and potentially torpedo my own efficiency) so I did it on contrived side projects.
raises hand

My current workload is mostly a bunch of data-collect scripts (hitting APIs, building a CSV, loading that to cloud storage and databases), plus prototyping small web apps for internal limited span projects. Testing doesn't make much sense for our current tasks, but I also really don't want to be left in the dust.

I need to start doing this. Any recommendations on where to start? I'd consider myself a pretty experienced python developer, that has not only not done unit testing, but have actively avoided it.

On the web side, any generators that create unit tests I normally delete...I know it's terrible.

Don't drink the kool-aid.
I’ll second that. I owe a great amount to those willing to publicly denounce TDD.

If I had been a working developer as this nonsense ramped up, I would have avoided it too. Nobody really does TDD. It’s a mythical concept.

Some sanity checks are fine, and some integration tests. Unit tests are often a pit of time waste, depending on the unit. I aim for my unit tests to look like integration tests.

> Nobody really does TDD. It’s a mythical concept.

That is 100% not true it is far from a "mythical concept" and you should not be misguiding devs.

Where do you think your testing suite is from? You might even be using their code who knows.

If there's any consistency to your work, you can always write sanity check "tests". My friend works in a Python shop, and for a lot of their infrastructure work, they'll write stuff like "assert that the database has between at least 20_000 records" in it. Many of there tests were reactions to little things that went wrong at some point in the past, but he's said it really helped improve the quality of their stuff over time!