(Unit) Testing at REKKI (backend)
Hi,
TLDR:
* test your core, make sure your core is strong
* don't test your http api
* don't mock
* don't test writing and reading from the database
* don't complicate your code to make it testable
* ... unless you deem fit
Long:
I want to address testing, because I see we have 2 camps that are
somewhat incompatible and if I don't address it now it will create some
issues.
1: people who test what they think is appropriate
2: people who test everything
The ratio at the moment is about 30% test everything, and the rest
test ad-hoc. So I decided to create more strict guidelines about what
we should test, and how we should test.
This is open to some commentary, but not as much as you would like,
the topic is incredibly controversial, and I will have to make a
decision and stick with it for the foreseeable future.
First I want to address the "TDD, DTD TDT DDT whatever", most of those
I think are complete bullshit, you are free to disagree with me. In
general I would advise you to not follow, pets follow.. just do what
you think is good. Tech is going in circles, old is new again, and it
is the same shit, now with lambda functions we are back to
CGI.. anyway I digress..
(Saying 'don't follow' and wanting to follow me is some intense
hypocrisy, but I will accept your challenge)
Coding for 20+ years I have formed my opinion about the value of
bullshit tests, and how they break whole products, handicap designs and
make refactoring a bitch, and I have also seen incredibly valuable
tests that make the whole codebase better and empower whole teams to
deliver with unprecedented speed. There is no rule by which you can
put a test in class BAD or GOOD, that's it, as in on paper it looks
great, in practice its horrible, same with infrastructure and
architecture, if you apply "best practices" blindly, you end up with
complicated abomination.
That being said, I want you guys to trust yourselves, and understand
that testing does not make your code better, *thinking* makes your
code better. Team work makes your code better. Knowing that when shit
happens your team has your back, and you will fix the issue together,
this is better. Bad tests can and will hurt our speed. We need to be
fast for at least 1 more year.
I will give you an example in pseudo code:
handle /set_something, func {
input := bind(request)
begin transaction
select from A where x=input.X
select from B where y=input.Y
update B set z=input.Z
commit
return A+B
}
We have a lot of code that just does things like that, when you unit
test with mocking, what exactly are you testing?
another example:
https://github.com/rekki/go-query (95% coverage), its like a rock, we
use it in almost every project and we are confident in it because of
the exhaustive testing.
I am not saying do not write tests, I am saying, do not write tests
that don't test anything. If bug happens or you see problematic area
use common sense (which is not common).
Test your core.
We need 1 more year of speed. Keep that in mind.
PS: I will also publish this on our eng blog so people are aware of the
culture we are having before they apply.
-b