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

Most Unit Testing Is Waste (2014) [pdf]

rbcs-us.com

Post reply on HN
Print view View original

101–110 of 164 posts

Re: Most Unit Testing Is Waste (2014) [pdf]

#101

Post by raverbashing »

walshemj wrote: post #85
acjohnson55 wrote: post #29

Earlier quoted context omitted.

What if most type system security is a waste? I don't personally believe this is the case, but I also can't tell you I know it to be false. What I do know is that types have a non-zero cost, and I think sometimes that's ignored, and only their benefits are acknowledged. But the efforts to bring types to historically dynamic languages show that not all common dynamic language idioms are amenable to reasonable type sig…

Apart from a bit more typeing up front I cant see many costs to typing.

That's because you (and many others) are drinking the static typing koolaid

Now try serializing things in XML instead of JSON. But not one type of message, multiple types, with flexible formats.

"Oh but this never happens" except it does.

Not to mention the iteration speed whenever you need to fix something.

Re: Most Unit Testing Is Waste (2014) [pdf]

#102

Post by BaronSamedi »

This paper is emblematic of a serious problem in the software development field: lack of empirical research. It is unsurprisingly filled with opinion and anecdote, with little mention of research in the area. And in the one actual study cited, "Does Test-Driven Development Really Improve Software Design Quality?", the author mis-characterizes the findings. Not that there is a huge set of research on unit testing to refer to--there isn't--and hence the problem.

"Software development has been characterized from its origins by a serious want of empirical facts tested against reality, which provide evidence of the advantages or disadvantages of the different methods, techniques or tools used in the development of software systems."[1] In my view, the best thing we could do is to adopt "Evidence-Based Software Engineering"[2] as other disciplines have. This is more likely to have a major positive impact than the newest and hottest language, tool, or technique.

[1] Reviewing 25 Years of Testing Technique Experiments. https://www.researchgate.net/publication/220277637_Reviewing...

[2] Evidence-Based Software Engineering. https://dl.acm.org/citation.cfm?id=999432

Re: Most Unit Testing Is Waste (2014) [pdf]

#103

Post by phereford »

fogetti wrote: post #98

The thing is that most people don't understand that the code needs to be tested anyway. If you don't test it, you are just an idiot who has no proof that the code does what it claims to do. Now because you have to test it anyway, you can just simply spend the same time writing a unit test instead of executing the code with manually configured non-repeatable test cycles, a.k.a clicking through the UI, or sending Postm…

To add to this sentiment, tests also give teams confidence that is needed. It gives engineers confidence when developing new features because the test suite will break if you introduce a regression. It gives engineers confidence during deployment/CD.

While the tangible benefits of unit tests are very important, there are other intangible benefits that are equally important.

Re: Most Unit Testing Is Waste (2014) [pdf]

#104

Post by Frost1x »

BaronSamedi wrote: post #102

This paper is emblematic of a serious problem in the software development field: lack of empirical research. It is unsurprisingly filled with opinion and anecdote, with little mention of research in the area. And in the one actual study cited, "Does Test-Driven Development Really Improve Software Design Quality?", the author mis-characterizes the findings. Not that there is a huge set of research on unit testing to r…

I agree entirely. The more tendency there is to push development as an "engineering" discipline, the more evidence based research needs to be used to solidify or disprove certain development dogmas repeated over and over again, which in many cases, seemingly have no empirical evidence beyond a few anecdotal success cases.

This is the norm in the industry, "you're doing it wrong, the best way is this way..."--based on what evidence that pertains to this case or has proven generalized success applicable here?

In most cases, it's someone's successful anecdotal experiences which worked for the specific cases they were involved with. That doesn't mean those approaches can be abstracted away and generalized to all cases, but many in this industry do that regularly and critique others' approaches based on that. It becomes this competitive ego contest: well my work was at x, y, z solving q and was successful--making me an authority on a, b, c's problems solving p because x, y, z is a leader (appeal to authority fallacy)... etc.

It's one thing to treat development as much of an art (which to me, it very well still is) but once you start treating it as a concrete discipline, you need to provide the lyme, cement, aggregates, water... evidence and studies showing approaches and how they faired across controls and varied cases.

Re: Most Unit Testing Is Waste (2014) [pdf]

#105

Post by floriol »

seppel wrote: post #90
quanticle wrote: post #46

Earlier quoted context omitted.

The problem is that sophisticated type systems only catch a subset of the bugs that a unit test can catch. For example, let's say I'm adding the ability to transfer funds from one account to the other in a banking application. I want to display a warning when the amount of money being transferred is over a certain percentage (let's say 95%) of the funds in the account. That's pretty easy to do in a unit test: create…

While I agree that this is hard to implement with a type system, I never want to see this implemented as a unit test. What you describe is a real use case that I personally want to have tested on a real system with all the stuff in place (but test database instead of the real one). It has nothing to do with one unit you can test on its own. And the crucial problem here is that you tie your testing code on the inner w…

With TDD, writing unit tests accompanies writing code - which in itself necessities thinking in terms of testability, which is a good thing making the program's components more separable. Regarding the former example, mocking only a single part where it connects to other parts of the system (for example some interface through which it sends warnings to users) is easy and makes the resulting code better (eg, easy to replace the notification manager).

Re: Most Unit Testing Is Waste (2014) [pdf]

#106

Post by walshemj »

osrec wrote: post #91
walshemj wrote: post #85

Earlier quoted context omitted.

Apart from a bit more typeing up front I cant see many costs to typing.

They can also be more difficult to refactor and adjust at a later date. This can be especially problematic if you're in an environment where logic needs to be altered rapidly in response to changing external conditions/requirements.

Can you give some examples why - do you mean changing a variables type? that should jut be a matter of a find and replace.

Re: Most Unit Testing Is Waste (2014) [pdf]

#107

Post by jrhurst »

cryptica wrote: post #64
njharman wrote: post #21

I did not read the article. I did read all comments Unit tests for the most part aren't about "testing". They are developer tool. To verify rthat modifications (refactoring, additions, bug fixes, etc) doesn't break contracts etc. Oh and showing that your code is a codependent mess of poorly isolated spagehtti, if your unit tests are hard to write, the code under test is a mess. Inittests are more useful in languages…

Unit tests don't guarantee that your code units are well designed. You can still write unit tests for spaghetti code. In fact, sometimes it encourages it because it encourages antipatterns like dependency injection; because developers get the urge to inject mock objects into the units from the unit tests. Just think about it at a high level. If your module depends on another module, is it really always necessary that…

I actually don't get where you are going with this breakdown. Can you give me an example.

Re: Most Unit Testing Is Waste (2014) [pdf]

#108

Post by walshemj »

raverbashing wrote: post #101
walshemj wrote: post #85

Earlier quoted context omitted.

Apart from a bit more typeing up front I cant see many costs to typing.

That's because you (and many others) are drinking the static typing koolaid Now try serializing things in XML instead of JSON. But not one type of message, multiple types, with flexible formats. "Oh but this never happens" except it does. Not to mention the iteration speed whenever you need to fix something.

?? sorry what do you mean, I was happily reading multiple types of logs with multiple different format records for a Billing system using statically typed PL/1G in the 80's

Apart from both json and XML are a PITA to work with in the first place

Re: Most Unit Testing Is Waste (2014) [pdf]

#109

Post by walshemj »

sjy wrote: post #96
dahfizz wrote: post #92

Earlier quoted context omitted.

The added "difficulty" is just the cost of doing a proper, correct refactor. Dynamic languages are not helpful just because they let you write bugs faster.

Developers are expensive though. If dynamic languages let you write buggy code in half the time that it would take to write perfect code in a static language, that would be an acceptable trade-off in many contexts.

Fixing bug later on get progressively more expensive, I though we had got over the KLOC metric decades ago.

Re: Most Unit Testing Is Waste (2014) [pdf]

#110

Post by methyl »

fogetti wrote: post #98

The thing is that most people don't understand that the code needs to be tested anyway. If you don't test it, you are just an idiot who has no proof that the code does what it claims to do. Now because you have to test it anyway, you can just simply spend the same time writing a unit test instead of executing the code with manually configured non-repeatable test cycles, a.k.a clicking through the UI, or sending Postm…

> If you don't test it, you are just an idiot who has no proof that the code does what it claims to do.

Does having tests make it any different? You would need to test those tests to make sure they are testing the right thing after all (ad infinity).

Post reply on HN