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

The day I started believing in unit tests

mental-reverb.com

Post reply on HN
Print view View original

241–250 of 269 posts

Re: The day I started believing in unit tests

#241

Post by domano »

toenail wrote: post #75
domano wrote: post #32

Earlier quoted context omitted.

Dont take this the wrong way, but this is the answer i would get from enterprise devs usually when pointing this out. Then i would realize that their definition of a real issue was completely removed from any business or user impact, but geared more towards their understanding of the process detail in question. I would argue that there certainly are some good places for unit tests, like if you have some domain-driven…

> this is the answer i would get from enterprise devs usually when pointing this out Yes, exactly what I thought, that's what you would hear from somebody who has experience working on large code bases with many contributors.

Ironically my experience has been that these responses came from people working in enterprise silos with few collaborators. Your mileage may vary.

Re: The day I started believing in unit tests

#242

Post by MoreQARespect »

randomdata wrote: post #220
MoreQARespect wrote: post #207

Earlier quoted context omitted.

>Kent Beck, who invented the term unit test, was quite clear that a unit test is a test that exists independent of other tests I vaguely remember him also complaining that there were too many conflicting definitions of unit tests. Maybe that can be solved with another definition? https://xkcd.com/927/ or maybe not. I dont know many people who would describe a test that uses playwright and hits a database as a unit te…

> He may have coined the term but that does not mean he owns it. Certainly not, but there is no redefinition that is anything more than gobbledygook. Look at the very definition you gave: That's not a unique or different way to write tests. It's not even a testing pattern in concept. That's just programming in general. It is not, for example, unusual for you to use an alternative database implementation (e.g. an in-m…

The definition I gave is the one people use. Hate or love it youre not going to change it to encompass end to end tests and neither will Kent Beck. It's too embedded.

Re: The day I started believing in unit tests

#243

Post by pjc50 »

pfdietz wrote: post #123
throwaway290 wrote: post #118

Earlier quoted context omitted.

It matters enough that the question "does static typing dramatically reduce the benefits of unit testing" is an open question or at least seriously discussed in the industry. All other replies are about dynamic languages.

Why isn't the question "does adequate testing dramatically reduce the benefits of static typing" asked? Why is static typing privileged by default?

It's not "privileged", it's better.

Re: The day I started believing in unit tests

#244

Post by IanCal »

donatj wrote: post #21

I was ambivalent on unit tests until I discovered how much the mere act of writing them was finding bugs. I very vividly remember writing a test for a ~40 loc class of pure functions. I started out thinking the exercise was a waste of time. This class is simple, has no mutable state, and should have no reason to change. Why bother testing it? By the time I was done writing the test I had found three major bugs in tha…

I had this kind of thing when it came to property based testing.

I built a property based testing library for ActionScript 3 (a fun journey in itself, with full test case reduction).

I was testing my testing library, and tried one of the most basic tests:

    For any object A
        A == decode(encode(A))
And discovered the fun of floating point values not being perfectly representable as strings.

The more significant one came from testing a UI library we'd built for TVs (so you has up, down, left, right as movement). We had in the spec that if you moved focus by pressing right, pressing left would take you back to the thing you were on before. The test looked something like

    For an arbitrary series of API calls generating the UI:
        For an arbitrary list of movements the user makes:
            If the focus changes, pressing the opposite direction moves your focus back where you came from
Now, this was actually very easy to write as a test, but it's extremely powerful. It found a bug in an interesting corner case, so I fixed it. Fixing the bug broke an existing unit test. I checked and the unit test correctly tested something in the spec.

The spec was inconsistent, but because we'd tested explicit examples it had never been spotted. I've been a convert since.

I've never implemented property tests in an existing project without finding some bug.

I don't recommend building your own property testing library unless you really want to, I highly recommend in python hypothesis: https://hypothesis.readthedocs.io/en/latest/

Re: The day I started believing in unit tests

#245

Post by funcDropShadow »

pjc50 wrote: post #243
pfdietz wrote: post #123

Earlier quoted context omitted.

Why isn't the question "does adequate testing dramatically reduce the benefits of static typing" asked? Why is static typing privileged by default?

It's not "privileged", it's better.

A bold claim, which is obviously false. To see that compare Clojure's dynamic type system with C's static type system. So perhaps a more nuanced stance is needed.

Re: The day I started believing in unit tests

#246

Post by funcDropShadow »

mayoff wrote: post #209
pfdietz wrote: post #123

Earlier quoted context omitted.

Why isn't the question "does adequate testing dramatically reduce the benefits of static typing" asked? Why is static typing privileged by default?

I wouldn’t say static typing is privileged, but that testing is disadvantaged, because, in the words of Edsger Dijkstra, “Program testing can be used to show the presence of bugs, but never to show their absence!” https://www.cs.utexas.edu/users/EWD/transcriptions/EWD02xx/E...

We could paraphrase Dijkstra --- with some liberty -- to say, "Formal verification of programs can only show the specification is fulfilled, not that the specification is adequate."

Re: The day I started believing in unit tests

#247

Post by Tainnor »

IanCal wrote: post #244
donatj wrote: post #21

I was ambivalent on unit tests until I discovered how much the mere act of writing them was finding bugs. I very vividly remember writing a test for a ~40 loc class of pure functions. I started out thinking the exercise was a waste of time. This class is simple, has no mutable state, and should have no reason to change. Why bother testing it? By the time I was done writing the test I had found three major bugs in tha…

I had this kind of thing when it came to property based testing. I built a property based testing library for ActionScript 3 (a fun journey in itself, with full test case reduction). I was testing my testing library, and tried one of the most basic tests: For any object A A == decode(encode(A)) And discovered the fun of floating point values not being perfectly representable as strings. The more significant one came…

Floating point values are definitely perfectly representable as strings - worst case, you just output the binary as a string - but what you may refer to is that many exact fractions can't be represented exactly as floats and/or that floating-point arithmetic doesn't obey "normal" rules of arithmetic (e.g. addition isn't associative).

Re: The day I started believing in unit tests

#248

Post by IanCal »

Tainnor wrote: post #247
IanCal wrote: post #244

Earlier quoted context omitted.

I had this kind of thing when it came to property based testing. I built a property based testing library for ActionScript 3 (a fun journey in itself, with full test case reduction). I was testing my testing library, and tried one of the most basic tests: For any object A A == decode(encode(A)) And discovered the fun of floating point values not being perfectly representable as strings. The more significant one came…

Floating point values are definitely perfectly representable as strings - worst case, you just output the binary as a string - but what you may refer to is that many exact fractions can't be represented exactly as floats and/or that floating-point arithmetic doesn't obey "normal" rules of arithmetic (e.g. addition isn't associative).

I'll clarify, as yes it's possible, but not using the built in conversions from strings to floats. That is, the following is not true for all x: Number(String(x)) == x

Re: The day I started believing in unit tests

#249

Post by joshjje »

donatj wrote: post #21

I was ambivalent on unit tests until I discovered how much the mere act of writing them was finding bugs. I very vividly remember writing a test for a ~40 loc class of pure functions. I started out thinking the exercise was a waste of time. This class is simple, has no mutable state, and should have no reason to change. Why bother testing it? By the time I was done writing the test I had found three major bugs in tha…

I think they are definitely valuable. My issue is I would have to disassemble most of the large legacy code base to be able to effectively test things, and a large part of it is UI (Windows Forms). I know you can do it, but just takes so much time and effort. We do have some though.

Re: The day I started believing in unit tests

#250

Post by joshjje »

Tainnor wrote: post #247
IanCal wrote: post #244

Earlier quoted context omitted.

I had this kind of thing when it came to property based testing. I built a property based testing library for ActionScript 3 (a fun journey in itself, with full test case reduction). I was testing my testing library, and tried one of the most basic tests: For any object A A == decode(encode(A)) And discovered the fun of floating point values not being perfectly representable as strings. The more significant one came…

Floating point values are definitely perfectly representable as strings - worst case, you just output the binary as a string - but what you may refer to is that many exact fractions can't be represented exactly as floats and/or that floating-point arithmetic doesn't obey "normal" rules of arithmetic (e.g. addition isn't associative).

Sometimes a framework will do weird things, like convert it to scientific notation, or round it, or add a ton of zeroes. Like BigDecimal in Java and Decimal in C#. They can sneak up on you.
Post reply on HN