

Pinterest = No Unit Tests - mukaiji

One of the Pinterest engineer admitted at a tech talk that they have no unit tests. Instead, they only test stuff by "clicking buttons in the browser." For a site of that size, I was a bit surprised. How common of a practice (not having tests) is it for large sites?
======
mike-cardwell
My feeling and experience tells me that the vast vast majority of websites
have no unit tests. I suspect a lot more than 99% of them.

~~~
AznHisoka
Yep. Also Pinterest really isn't that complex an application. Clicking on
buttons and trying scenarios out is probably good enough (given the time they
have available). The major hiccups like server slowdowns, or concurrency
issues, or too much memory being used for a request are hard to unit test
anyway, and those are the real potential issues they face.

------
bradfordw
You don't get big by writing a lot of tests (or checks). You get big by
getting stuff done with competent people that pay attention to the changes
they apply. YMMV

~~~
ndunn2
When you reach a certain size, no amount of due diligence on your part can
ensure that your changes aren't going to break something in some other part of
the code base without automated tests. Do you think Google or Amazon gets by
without unit tests?

~~~
bradfordw
I'm not saying they're not useful, pinterest is hardly a giant in my opinion,
they do one thing and clearly do it well. I'm sure their position on unit
tests will change, hopefully before they are burned.

~~~
recursive
It is not impossible to have a large code base without unit tests. I'm sure my
employer's code base is in the millions of LOC. At least 99% is not covered by
unit tests. Probably 99.9%.

~~~
metadata
That might work for you, but is a bad idea in 99% of cases (I am not implying
that most code has tests in place). I guess your code changes very rarely. If
you have to change something in core part of application with a lot of
dependencies, good luck. Also, when several programmers are working on the
same part of code (perhaps in a span of 5-6 years), they will need some time
to understand code to be changed, then think more where something might break
if they change it. At the end, they will lose a lot time and still not catch
all the interactions with other code. It took me a lot of time to understand
why people want to write tests first, then code. It was more natural for me to
make optimal code, then test expected/unexpected inputs and edge cases. The
answer turned out to be that code ends up much cleaner and _all_ code paths
end up tested properly because you never write a single line of code which
isn't explicitly there to satisfy a test.

------
bradhe
I have a very heavy handed approach to testing because I fuck up the details a
lot. Testing keeps me from doing so by actively forcing me to look at the
details. I make up for time "lost" writing tests by A) writing code just plain
faster than my peers and B) in the time I save on regressions later.

I think every person and team is different so no one model or ethos to testing
will fit generically. Pinterest is doing well enough. If they don't need to
automate, so be it. When they bring on some more engineers, the dynamic will
change so maybe they'll need more automation then.

------
sixQuarks
Sorry for my ignorance, but can someone explain in simple terms what a unit
test is?

~~~
mukaiji
A unit test is a way to automate the diagnosis of your website. For example,
let's say your website allows people to create a user profile. You could (A),
verify that you can successfully create a profile by opening your web browser,
navigating to your site, creating a profile, and making sure you get a
successful response. That's fine and relatively quick to do. However, as your
code base grows in size, you don't want to have to redo this test manually
every time you add a new feature that could potentially break your user-
profile feature. Thus, and (B), comes in unit testing (or integration tests,
or simply tests), that automates the process for you. Every time you add a new
feature, you can run tests to verify that this new feature didn't break
something else in your code base.

