[–] taxation_is_slavery 0 points 1 point 1 point (+1|-0) ago (edited ago)
If you're paid by the hour they are wonderful wastes of time. Though I prefer more interesting things, if you hate the company you're doing work for it's one option.
[–] boater 0 points 1 point 1 point (+1|-0) ago (edited ago)
I think whether or not unit tests save you time depends on your development methodology.
They work well in conjunction with pure functional programming, where one might write a 10 line function, and then a 2 line test below it in the same file, where the test is just a boolean function equality test returning whether or not the primary function returned the expected return value when it was called with a handful of input parameters.
I would agree that writing unit tests for non-determinsitic input-output code or writing unit tests in a seperate file or folder than the code being tested can be a waste of time, but if you have your build system setup to automatically parse unit test signatures from your modules and automatically generate a custom binary to call them, they can be a convenient way to clarify an API and make it feel more stable during the process of writing it.
[–] TheGuyWithFace 0 points 1 point 1 point (+1|-0) ago (edited ago)
"Oh, well, good unit tests don't do that", and then these good unit tests never exist
But they very much do exist. It takes a fair amount of forethought - you have to design your system ahead of time to be modular and think about these things as you go, but good, non-brittle unit tests absolutely exist. If you're having to mock everything every time you write a unit test, that's probably a sign your code could use some refactoring.
[–] sparkybear 0 points 1 point 1 point (+1|-0) ago
I get the importance of some unit tests. But I don't think that they need to be done for everything. I don't agree with justletmevoat, but I also don't agree that we always need them. I think they are good for specific tasks that require either a lot of validation with a lot of moving parts, but I don't see them being useful for smaller things. Maybe because I haven't really done test-driven development, but the way I've seen them implemented in most cases seems like a waste of time.
[–] TheGuyWithFace ago
Oh certainly, I don't think unit tests belong everywhere. I mainly see them as useful for logic-heavy business rules that you know are going to be used for years to come. I can't really comment on TDD, I haven't done much of that either.
They are not so bad if you are doing modular functional programming and write your test functions as pure boolean functions accepting no arguments in the same file as the code they are testing. Then you can do a small amount of meta programming by writing a program to parse the function signatures of each module, build a list of your unit test signatures, and write them out to a new code file which prints their name and calls all of them in order, raising an error if any of them do not return True or 1. This reduces a lot of overhead associated with maintaining working unit tests. If you write your tests in the same file as the code they are testing, you won't accidentally loose any of them when a file gets renamed or moved.
[–] theonlylawislove ago
It sounds as if you do not know how to unit test.
They break stupidly when code changes, and people defend them saying "Oh, well, good unit tests don't do that"
They don't break stupidly if you are doing modular functional programming and write the unit test functions in the bottom of the exact same file as the functions they are written to test. This lets you keep related logic in the same place and automatically generate unit test binaries by parsing function signatures rather than creating them manually.
However, if you put your unit test functions in a different file or folder than your primary source code, then yes they will breakly stupidly whenever you need to rename things, as you will have to many more locations in which to remember to change the name.
In my experience the value of unittests really shows when you need to be sure that new features/changes doesn't break stuff that already worked. At the company I am now it is immensely useful that we have proper unittests for our application. It deals a lot with processing various kinds of input and the output needs to be consistent. I very rarely have to rewrite old unittests.
If you have the tests before you have the code you can make incremental changes and catch the errors without deploying the whole fucking system. If you never have the tests and you only have code then you always have to deploy the whole system to test. While every developer should know the build chain and the operational scenario not everyone should be setting up and deploying complex system tests. If your continuous integration/deployment does this then you are a rare gem.
[–] kherrera 0 points 1 point 1 point (+1|-0) ago
I agree with how time consuming and complicated it can be, but I disagree that it is useless.
If a unit test breaks and you know about it, then it did its job. Expectations have been changed and the error you see as a result of a failed test is a heads up. Depending on the type of project that is being developed, it is very useful in order to re-evaluate the changes that were made, or to update related processes. It's an excellent way to find regressions before they are pushed to production.
I personally find it tedious to write tests, but I appreciate the piece of mind I get even more after running the tests and getting back a clean result. Some would argue that a clean result doesn't really mean anything, but in practice it comes down to how well the tests were written.
[–] TheGuyWithFace 0 points 1 point 1 point (+1|-0) ago
Also, I find unit tests very useful for learning about the system I'm working with when I'm first coming onto a project. It's still tedious, but not as much so because I'm learning about how everything fits together as I write my test. Once I'm done I feel a lot more confident about modifying other parts of the codebase and working on bigger tasks.