do you test your code /g/? or is it overrated to do so?

What disgusting pseudocode is that?

The test- driven thing I find overrated, or at the very least, just not for me. I usually write tests for the interesting, non- trivial parts, or in reaction to a bug/performance problem. If I'm working on an existing codebase, not written by me or I haven't worked in it for a year or two, I also try to write tests for the code that I'm about to refactor or change otherwise.
But yeah, in general I don't strive for a high code coverage and try not to write too many tests for infrastructure/plumbing/trivial code instead focus on the interesting stuff.

Whats with that 6000 lines garbage API for a Todolist?

Testing is a waste of time, anyway.

>>61504401
only on real complicated code projects do I use unit testing, mostly for simple stuff I just test it with inputs and check the outputs

>>61504401
every serious company that releases code to the public should do TDD, if you just program for yourself you are free to decide yourself how or to which extend you want to test

TDD is not a meme, its useful if you consider your project serious

>>61504776

Nah, its a complete waste of time.In web(95% code monkey job)a pro does not need to test his code, because he has already written the same shit in his past projects.If an error happens, he already knows whats the problem, anyway.

>>61504401

Depends on the project. If it's some throwaway code that doesn't affect anything critical, some rudimentary integration tests are good enough.

If it's a sensitive business workflow or algorithm that you're working on, then every line of code has to be covered by at least one test suite.

Test coverage and quality depends entirely on the budget and the available resources. There are some projects where literally all QA is handled by Indian click monkeys and that's fine, too if you can live with the consequences. In a setup like this you will never (!) have continuous deployment and anything "agile" will be hard as fuck.

If you're a techie and you have enough budget available, you should always go for unit tests where they make sense, integration test your entire system and have some other guy (preferably a qualified tester) provide an automated system test suite.

This way you have immediate feedback on small, moving parts (unit, integration) and delayed feedback on overall system health.

I run tests on pretty much all of my code. I mostly do numerical stuff, so it's often difficult for me to tell if my code is actually working correctly without running some sort of test.

Most code I write is not commercial (end user) stuff, so I always make it as self checking as possible for quick debugging.

If it's a product I'm trying to sell or otherwise put into production, I'll TDD

If it's some developer-centric CLI tool for myself and others that will do just one thing well, fuck it, long as it works

>>61504401
I just do it so that I can have a Build Passing Travis badge on my GitHub repo

>>61504401
I'm all for unit testing if you your situation allows it.
I'm working on a project that started 2 years ago where multiple teams are involved. My team it the only one unit testing our outside facing APIs which prevents most crap code written by my pajeet-tier co-workers from getting integrated. Sadly this doesn't stop them from also writing new shitty unit tests that don't even meet the actual requirements.
But the other teams constantly commit and deploy shit that breaks major parts of their systems and some don't even test the changes they've done.

TDD on the other hand (writing tests before implementing changes/features) doesn't work if the requirements are badly documented or ambiguous.

File: 14237488_1774606086151053_7372566033666423778_n.jpg (38KB, 640x640px) Image search: [Google]

38KB, 640x640px

>>61504725
mocha.
A testing framework for JS.
If you find this disgusting, i dare you to take a look at gherkin syntax.