> I don't know what to do with tests, to be honest. ... HN what do you think?
Well, since you asked!
The most valuable tests in any system is functional tests. Unfortunately most tests are unit tests that give little value.
Here's something that I encountered recently in the wild. Imagine a situation like this, a calculation process with three distint black boxes of code.
Block A - Pull data from 3rd party source
Block B - Distribute data to individual nodes (multi-threaded environment)
Block C - Individual nodes processing data
Each one of these blocks is around fifty thousand lines of code, each one of these blocks has hundreds if not thousands of unit tests. Every line of code is tested by a unit test. Yet there is a very real and dangerous bug in the system.
Why? Because the object passed from B-C has a transient variable and when it is serialized and deserialized that value is lost and reverted to the default value. Now most places leave this value as the default, so it's only one out of a thousand customers that have this problem, but when they do it's a huge problem.
Functional tests is the process of saying "I put meat/spices on this side and sausage comes out the other" it doesn't try to determine the RPM of the grinder, the number of bolts, the rotation of the gears, or the type of metal used to build the sausage-maker. It is simply the process of determining that meat becomes sausage. Functional tests have high value and are absolutely worth knowing.
In most CRUD applications Unit Tests generally wind up testing that the universe still exists as expected (true is still equal to true, zero is not one, and a null value is not the same a string, oh happy days the system works!).
That's not always the case. If you are working on something that is more advanced, say something that should measure the chance a hurricane might knock down a given 3d model you'll wind up having a huge stack of unit tests, and these will be very valuable. More often than not you'll know they are valuable as they'll be spent proving the science behind the application, and not simply that the application 'does something'.
That bug with the transient variable. You could only would really catch that if you had e2e or integration tests covering a majority of the code in your application, right? Even then, only if you were to persist the data, read the data back out, then again run more tests on it.
I accept testing isn't a silver bullet, but ouch.
As a general strategy, it sounds like it's better to run your higher level tests as a gauntlet (feeding the result of test one into test two) then with tightly controlled inputs (using explicit data for each test).
Well, since you asked!
The most valuable tests in any system is functional tests. Unfortunately most tests are unit tests that give little value.
Here's something that I encountered recently in the wild. Imagine a situation like this, a calculation process with three distint black boxes of code.
Block A - Pull data from 3rd party source
Block B - Distribute data to individual nodes (multi-threaded environment)
Block C - Individual nodes processing data
Each one of these blocks is around fifty thousand lines of code, each one of these blocks has hundreds if not thousands of unit tests. Every line of code is tested by a unit test. Yet there is a very real and dangerous bug in the system.
Why? Because the object passed from B-C has a transient variable and when it is serialized and deserialized that value is lost and reverted to the default value. Now most places leave this value as the default, so it's only one out of a thousand customers that have this problem, but when they do it's a huge problem.
Functional tests is the process of saying "I put meat/spices on this side and sausage comes out the other" it doesn't try to determine the RPM of the grinder, the number of bolts, the rotation of the gears, or the type of metal used to build the sausage-maker. It is simply the process of determining that meat becomes sausage. Functional tests have high value and are absolutely worth knowing.
In most CRUD applications Unit Tests generally wind up testing that the universe still exists as expected (true is still equal to true, zero is not one, and a null value is not the same a string, oh happy days the system works!).
That's not always the case. If you are working on something that is more advanced, say something that should measure the chance a hurricane might knock down a given 3d model you'll wind up having a huge stack of unit tests, and these will be very valuable. More often than not you'll know they are valuable as they'll be spent proving the science behind the application, and not simply that the application 'does something'.