Testing at Facebook

Posted May 4, 2013 11:48 UTC (Sat) by drothlis (guest, #89727)
In reply to: A report from the Google Test Automation Conference by giraffedata
Parent article: A report from the Google Test Automation Conference

> I don't consider the running of code that the coder does testing.

If you mean a developer running a program as he or she is developing it,
then I agree with you completely. Simon's talk was about *automated*
testing.

> time spent testing takes away from time that could be spent doing
> something more fun like designing and coding.

I imagine that Facebook looks for developers that don't think testing is
beneath them. Automated testing has its own engineering challenges that
are just as fun to design & code, as production software has. :-)

Testing at Facebook

Posted May 4, 2013 18:26 UTC (Sat) by giraffedata (guest, #1954) [Link] (1 responses)

Simon's talk was about *automated* testing.

And in that context, I assumed the testing he was talking about was developing the test cases for the automated test machinery to run. And that's something I would want done by someone other than the author of the code to consider it a real test.

I imagine that Facebook looks for developers that don't think testing is beneath them.

They would also have to look for developers who enjoy testing as much as designing and coding.

Of course, they might let some talented, affordable designers and coders go to competitors in so doing.

Testing at Facebook

Posted May 7, 2013 17:15 UTC (Tue) by drothlis (guest, #89727) [Link]

> developing the test cases [... is] something I would want done by
> someone other than the author of the code to consider it a real test.

That's a very important point. Some possible solutions (or at least
mitigations):

+ Code review: Tests should be given just as much, or more, scrutiny
during code reviews as the code-under-test itself.

+ Pair programming: Pair up on a given feature, with one developer
writing the tests and the other developer writing the implementation;
swap roles for the next feature/iteration/sprint.

+ Integration tests: End-to-end integration tests will, by their nature,
cover more than a single developer's work, so the developer writing
the test is, by definition, not testing only his or her own code.
The same is true for isolated component tests, depending on the size
of the component.