While in certain applications I might agree with you, for a full-featured website like voat I just have to disagree with you. Unit tests can be annoying to write, and their benefit might not be super apparent at first, but in the long run, well written tests are very very valuable IMO.
They break stupidly when code changes, and people defend them saying "Oh, well, good unit tests don't do that", and then these good unit tests never exist, and you've got to stub or mock everything, so your tests don't test any fucking thing useful, and then the API for the DB library changes or you have to update versions and you have not only update your tests to that, but also the fucking stubs.
Fuck unit tests - out of all the different kinds of testing possible it is the most useless.
"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.
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.
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.
I've never heard of writing unit tests in the same file either. I've always seen them done in a separate file. Usually you're working on "person" and have "persontests". Maybe that's my inexperience though.
It depends upon your language and setup. When programming in a language like C there are no costs to including tests as static inline functions inside of the header file because the compiler won't bother to include this code in the final binary of anything which doesn't reference them.
The primary benefit is that, if you need to make a copy to test multiple versions of an API concurrently without branching the code repository, then you won't need to also copy and rename the corresponding unit test file as well.
This is just a strategy I use to increase the probability that I will maintain complete test coverage when experimenting with the design of an API during early development, but like all strategies it won't be universally applicable for all scenarios.
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.
Yeah. Where I'm working we have one dev who is adamant about it, but he's come from some really old school code shops and worked in large corporations. it seems like these huge enterprise solutions would require a lot of testing to ensure that things are functioning properly.
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.
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.
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.
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.
I agree with @TheGuyWithFace. While unit tests are very annoying to write and more work upfront, the benefit of knowing your broke that ancient obscure method X with a recent change prior to deployment instead of a user asking why X no longer works "like it used to" makes it all worthwhile.
24 comments
4 u/ptd 09 Jul 2015 07:09
It looks like they sort of do. If you look in the UnitTests.cs file there's a few tests in there.
https://github.com/voat/voat/blob/master/Whoaverse/UnitTests/UnitTests.cs
But it doesn't seem like it's something they do consistently (last commit was May 19).
2 u/justletmevoat 09 Jul 2015 05:57
Unit tests are overrated.
4 u/TheGuyWithFace 09 Jul 2015 06:18
While in certain applications I might agree with you, for a full-featured website like voat I just have to disagree with you. Unit tests can be annoying to write, and their benefit might not be super apparent at first, but in the long run, well written tests are very very valuable IMO.
1 u/justletmevoat 09 Jul 2015 06:20
They break stupidly when code changes, and people defend them saying "Oh, well, good unit tests don't do that", and then these good unit tests never exist, and you've got to stub or mock everything, so your tests don't test any fucking thing useful, and then the API for the DB library changes or you have to update versions and you have not only update your tests to that, but also the fucking stubs.
Fuck unit tests - out of all the different kinds of testing possible it is the most useless.
1 u/TheGuyWithFace 09 Jul 2015 06:24
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.
1 u/sparkybear 09 Jul 2015 07:51
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.
0 u/boater 09 Jul 2015 12:38
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.
0 u/sparkybear 09 Jul 2015 18:08
I've never heard of writing unit tests in the same file either. I've always seen them done in a separate file. Usually you're working on "person" and have "persontests". Maybe that's my inexperience though.
1 u/boater 09 Jul 2015 18:37
It depends upon your language and setup. When programming in a language like C there are no costs to including tests as static inline functions inside of the header file because the compiler won't bother to include this code in the final binary of anything which doesn't reference them.
The primary benefit is that, if you need to make a copy to test multiple versions of an API concurrently without branching the code repository, then you won't need to also copy and rename the corresponding unit test file as well.
This is just a strategy I use to increase the probability that I will maintain complete test coverage when experimenting with the design of an API during early development, but like all strategies it won't be universally applicable for all scenarios.
0 u/TheGuyWithFace 09 Jul 2015 15:48
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.
1 u/sparkybear 09 Jul 2015 18:11
Yeah. Where I'm working we have one dev who is adamant about it, but he's come from some really old school code shops and worked in large corporations. it seems like these huge enterprise solutions would require a lot of testing to ensure that things are functioning properly.
1 u/taxation_is_slavery 09 Jul 2015 06:44
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.
1 u/boater 09 Jul 2015 12:54
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.
0 u/Xyc0 09 Jul 2015 06:58
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.
0 u/boater 09 Jul 2015 12:26
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.
0 u/theonlylawislove 11 Jul 2015 22:24
It sounds as if you do not know how to unit test.
0 u/justletmevoat 13 Jul 2015 02:31
I'm sick of having other people's unit tests break for shitty reasons.
1 u/Tenayden 09 Jul 2015 18:48
I agree with @TheGuyWithFace. While unit tests are very annoying to write and more work upfront, the benefit of knowing your broke that ancient obscure method X with a recent change prior to deployment instead of a user asking why X no longer works "like it used to" makes it all worthwhile.
1 u/theonlylawislove 09 Jul 2015 09:31
Skimur will!
https://github.com/skimur/skimur