
Principles of Automated Testing - lihaoyi
http://www.lihaoyi.com/post/PrinciplesofAutomatedTesting.html
======
valuearb
I think their definition of automated testing is good. Myself I find unit
testing to not be worth the trouble, most unit tests I've seen in mobile apps
are just checking obvious inputs for obvious outputs. Unit tests take time
away from writing good code, can never be complete (even 100% code coverage
isn't 100%), and take time away from working on the most important part of any
software, features.

I prefer to spend my extra time writing code that validates all inputs and all
possible error conditions, and logging exceptional situations that can't be
handled within the error system.

Tests I find valuable are ones that explore performance and data quality
issues. For example in my current project the original developers decided to
assume our server APIs always return nil data (hopefully with an error) or
that they will return perfectly formed JSON, and if not, would crash. The
truth is it's unlikely the server doesn't return poorly formed JSON for a
"successful" request, but I wrote code to test 3,000 stores with various data
inputs just to test a single API to find out if it did.

Of course I"m not writing a server API. If I was, I'd definitely be writing
unit tests. But in a mobile app, there is plenty of work to do to improve the
app directly that provide far more value than most unit tests can.

~~~
adrianN
There are of course lots and lots of ways of writing useless tests, but I
don't think it's right that the most important part of any software are its
features. I for example prefer software with fewer features that works
reliably over software that includes everything and the kitchen sink but
crashes regularly.

~~~
dom0
> fewer features

My two 0.02 € on this:

Features have external and internal complexity. External complexity is
documentation, usage, support while internal complexity is time spent on
maintenance and development, increased complexity of the code, reduced
stability etc.

External and internal complexity are unrelated, and when deciding whether to
add some feature _both_ must be considered against the _assumed_ advantages of
the feature.

------
karmakaze
> if you want to check a single function's behavior with 10 different sets of
> primitive arguments, using integration tests to test it may mean you end up
> setting-up and tearing-down an application process 10 times: a slow and and
> wasteful use of your compute resources

This is only true if the test is run in process and there it is stateful.
Performing out of process tests on stateless units are very effective.

