@electrumsv is on PowPing!

PowPing is a place where you can earn Bitcoin simply by socializing, for FREE.
Never tried Bitcoin? It's OK! Just come, socialize, and earn Bitcoin.
Check out electrumsv's activities

ElectrumSV Development

visit channel home
Total Economy: 0.01 USD

What are test driven development best practices?

ElectrumSV has a lot of tests. They do a lot of invaluable things like run older wallet formats through the migration process. When changes are made that break wallet upgrades and a myriad of other things, we can detect them.

Tests are costly

A test is inherently coupled to implementation. This inherently makes it potential technical debt, and it means that if you want to rewrite things to remove technical debt the tests should either be completely discarded or rewritten to a large degree. They are a barrier to improving code. It might be argued that time can be spent abstracting a test so that it can be future proof, but writing and maintaining tests is already a costly endeavour.

Writing better tests

I suspect the only way to write better tests is much like anything else, to write any tests, which are going to be inherently bad and by doing so gaining experience writing tests. Ideally your code will be reviewed by another programmer who can guide you in this process, but then you have the risk of exposure to bad advice and learning bad habits.

Could there be educational material that provides guidelines to help people learn good habits in writing more effective tests? Probably. But chances are that this material will be written by individuals in the ivory tower who have not worked on any real world projects, and will push educational norms over useful practices and knowledge.

Where is the references for dealing with the cost of tests and reducing them? I have yet to see any, therefore it cannot exist. Also many of the textbooks I have on my shelf are high on dogma and low on substance of use. I suspect that if there is any such reference out there, it is lost in a forest of contractually padded verbiage.

Best practices

I suspect that someone who is writing tests should aim to become good at documenting their tests. Often when I come to tests that others have written, or that I wrote in a past life that is no longer accessible to me, I do not know exactly what is being tested. What is good test documentation? How would I know, it likely depends on the test and requires experience maintaining tests to get a feel for it. Hashtag more art than science.

I suspect that someone who is writing tests should aim to use as little abstraction as possible in their tests. Abstraction hides what is going on by changing the visible surface, and means that to fully understand something you need to understand more pieces of code, including other beneficiaries of the abstraction. When your program is layers of abstraction in this way, it becomes more fragile. And similarly if you use abstraction in your tests, they also become more fragile. Is some level of abstraction good and if so, what is it? How would I know, it likely depends on the test and requires experience maintaining tests to get a feel for it. Hashtag more art than science.

I suspect that there are tests with a long life-time and tests with a short life-time, and that a programmer should be able to recognise either depending on how tightly coupled the test is to logic within the tested application. They should also be able to write each type of test differently, to suit the needs. This is likely to be easier to gain a feel for, and to be guided on, than the other aspects of testing.

Final thoughts

I wrote something here about how I am not a unit testing expert, and I think test driven development is one of those internet fantasies glommed onto by programmers who aren't that productive. But Powpress deleted it from under my fingers and Control-Z won't bring it back. So imagine it was still here, but much better written and better argued.

powered by powpress
link Tip
Share
tx
translate
isaiah_smith tipped:
0.01 USD
1 year ago