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

91–100 of 164 posts

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

#91

Post by osrec »

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.

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.

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

#92

Post by dahfizz »

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.

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.

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

#93

Post by dahfizz »

quanticle wrote: post #46
chongli wrote: post #14

Earlier quoted context omitted.

I'll say that any unit test for a bug which would have been caught by a more sophisticated type system is a waste. I don't know how much time people spend writing such "obsolete tests", but I doubt it's insubstantial.

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…

The parent never claimed that a type system means bug free code, or replaces all unit tests. However, it does mean you need less tests.

In a typed, compiled language you get some pretty nice guarantees just by getting your code compiled. In a dynamic language, you have no way to know if your code even runs until you have 100% code coverage.

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

#95

Post by chrisan »

dahfizz wrote: post #92
osrec wrote: post #91

Earlier quoted context omitted.

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.

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.

I wouldnt even call that difficulty. That is a bloody loved feature in my book

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

#96

Post by sjy »

dahfizz wrote: post #92
osrec wrote: post #91

Earlier quoted context omitted.

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.

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.

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

#97

Post by rstuart4133 »

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.

Try programming in Rust. The upfront cost in figuring out how to write the code to minimise unsafe()'s can be very high. This is because Rust's type system is so strong it both does the work of the garbage collector and catches things other languages would miss, like memory leaks.

That aside, that "bit" of typing can amount to a lot. Python programs are usually very compact compared to statically typed languages. Yes, this means writing more unit tests to cover the bits the type checker would have caught, but in my experience the total LOC with unit tests for 100% coverage in Python is still less than a statically types language.

That said, I still prefer statically types languages. The big difference between statically typing and unit tests is when the error is caught. Static typing catches the errors very early. In fact in modern IDE's that do incremental compiles it's literally after you have typed the statement. Errors that hang around tend to ripple through your code because your mental model is wrong, so catching them early means less errors in total. The effect can be large.

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

#98

Post by fogetti »

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 Postman requests, etc.

Also it's kind of selfish not to make something repeatable by others.

And as someone pointed out before me, unit tests are not about testing at all. It's a documentation about the system, and what it's supposed to do. Also it's the way to stop the next person who works on the code to ruin something by not knowing the business rules.

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

#99

Post by mobjack »

qznc wrote: post #65
mobjack wrote: post #37

Earlier quoted context omitted.

95% of the time when a unit test fails for me, it is the test that need fixing instead of my code. It hardly inspires confidence.

To me this suggests that there is no clear understanding what your units are supposed to do. My second theory would be that the unit tests are written by the inexperienced developers while the good developers write the other code.

The tests will involve 5 mocked dependencies just to test a simple if statement. They test the implemention and are a waste of time.

Isolated units that are well tested usually don't need to be updated in my experience so they rarely break.

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

#100

Post by hhjinks »

dep_b wrote: post #79

Doing a typical "front-end" mobile application I write the following tests: * Integration tests that test the API I get a ton of value out of it though it's sometimes hard to guarantee a certain state at the API's end. But I use them while building the API's but they also can detect any kind of problem after an API upgrade etcetera * Unit tests that test data transformations This is stuff like date formatting, buildi…

I personally find testing incoming APIs a waste. Sometimes I write tests to verify that I treat the incoming data correctly if I transform it in fancy ways, but other than that, you should trust the API contract. It's almost like writing tests for the frameworks you're using.

Granted, that's from a unit test perspective. Integration tests of APIs are invaluable. I wish we had them already where I currently work.

Post reply on HN