Re:Principles of Automated Testing
by italicbold on Saturday September 02, 2017 @06:57AM
(#15155344)
I have always thought that one of the most useful reasons for having unit tests is to help refactoring, but with the rapid change of js frameworks or even languages, it seems one is more likely to transition to something entirely different every 4 or 5 years. Which makes the roi much lower on some types of testing. Can anyone who has changed tech stacks/frameworks often for an app/site comment?
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.
> 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.
I realize there are scenarios in theory where it's easier to verify output than create it, but in practical terms (e.g. A web application) what would the difference be between a testthat validates all possible inputs/outputs and the actual program you're writing?
Re:Principles of Automated Testing
by travisjungroth on Saturday September 02, 2017 @04:32AM
(#15154943)
Why would definitely write tests for an API but not a mobile app?
An API has specific defined outputs and inputs.
Lots of mobile app code has inputs dependent upon a variety of events from network calls to user inputs, and it's "output" can be almost anything from UI state changes, pixel maps or database changes. Then your design group wants to change the UI, and you have to refactor everything, and rewrite every single unit test.
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.