Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Making Software Reliable: The Importance of Testability

codereliant.io

Post reply on HN
Print view View original

21–25 of 25 posts

Re: Making Software Reliable: The Importance of Testability

#21

Post by nescioquid »

gjsman-1000 wrote: post #5
diekhans wrote: post #4

Earlier quoted context omitted.

My view is that automated testing is not a substitute for QA, but an additional tool. It lets QA focus on harder to automated tasks. For unit tests, a developer is going to try something out anyway, so capturing it in a unit test for the future should be just a little extra work. Also, writing a unit test means the developer has minimally used what they are writing. Higher-level (system) testing, especially with GUIs…

There is one programming language that fascinated me (maybe it was Ada) where it tried to have some basic tests inline with the code, by defining basic guidelines for legitimate results of the function. For example, you could make a function called `addLaunchThrusterAndBlastRadius` (I know it make no sense, but bear with me), and then right alongside declaring it was an integer, you could put a limit saying that all…

Preconditions and postconditions around procedures. I thought that it was an innovation from Eiffel, though wikipedia lists Ada as an influence, so maybe it did originate there!

Re: Making Software Reliable: The Importance of Testability

#22

Post by drewcoo »

Lots of words. Still somehow misses the definition. And everything valuable about testablity's tiny Wikipedia page.

https://en.wikipedia.org/wiki/Testability

Testability is not the ability to write tests but the ability to write tests for a thing correlates with testability.

And worth mentioning to all of the (dev)ops folks who think they own observability . . . observability is a strict subset of testability.

Re: Making Software Reliable: The Importance of Testability

#23

Post by Nathanba »

gjsman-1000 wrote: post #2

I'm actually rather negative on automated testing. Every project, that has gotten rid of the Q/A team to rely on automated tests, hasn't exactly gone well. Windows being the obvious example, but there are others. I'm not seeing the quality improvement that should be there. And even when there are tests, elementary mistakes (like the time Windows 10 would delete your Documents folder) slip through the pipeline and scr…

My view now is that tests are mostly there as additional documentation and a form of cross cutting type checks. You have two functions with various parameters and then you write a unit test to document how these two functions interact with each other and you make sure that a certain beaten path remains working. It generally won't catch any bugs whatsoever but it's like having it documented that this is in fact a path and it is supposed to be there and it should remain maintained. Almost like a map of streets and thanks to the map you know that these paths are there and they need to be snowplowed even though maybe you don't remember why exactly there is a street here. It just is and you want it to remain in functioning order anyway. Even in teams I've not really seen unit tests catch any bugs but that may be because once you've written the code with tests it's so well documented and the purpose is so clear that people aren't going to forget how things work anymore. At that point most people won't "run into a wall" anymore because they can see the wall now.

Re: Making Software Reliable: The Importance of Testability

#24

Post by Nathanba »

natbennett wrote: post #3
gjsman-1000 wrote: post #2

I'm actually rather negative on automated testing. Every project, that has gotten rid of the Q/A team to rely on automated tests, hasn't exactly gone well. Windows being the obvious example, but there are others. I'm not seeing the quality improvement that should be there. And even when there are tests, elementary mistakes (like the time Windows 10 would delete your Documents folder) slip through the pipeline and scr…

I’ve worked on a large project that got more reliable after they removed the QA team. Removing the QA team was incidental to the quality improvement though — the QA team got removed because basically it was just producing a nightly report of problems that didn’t matter. What actually improved quality on that project was, basically, architecture improvements. A major subsystem was rewritten in a way that made large cl…

yes I think the way we use the word "bug" generally means that it's a bug from a human being's point of view. But automated tests are automated, maybe what they catch shouldn't even be called bugs but just type/check/assumption errors. Then the expectation is far more aligned with reality.. just because a unit test doesn't run successfully doesn't mean anything. You simply have to check the assumption and adjust the type check perhaps.
Post reply on HN