undefined | Better HN

0 pointslaureny12y ago0 comments

> Making tests part of language syntax is an interesting idea.

It's been tried many times before and it has always failed. A few reasons:

- It clutters the code

- If you need simple tests, asserts suffice

- If you need more sophisticated tests, write functional tests, separately

The approach offered by Pyret (along with similar ones, such as design by contract) are compromises that are the worst of both worlds.

0 comments

9 comments · 1 top-level

skrishnamurthi12y ago· 8 in thread

It's actually widely used in Racket already. Yesterday a lead programmer at a major financial institution told me that he liked that style so much, he'd incorporated it into his company's OCaml system, and they use it in their production systems (lots of high-volume trading). Hardly "failure"s.

Nevertheless, perhaps you could provide some pointers to the "many" projects that have tried it before?

Assertions are not tests. This is a fundamental misunderstanding of the difference.

Pyret's `check` blocks exist to write complex tests, separate tests from definitions, or write tests that cross multiple functional units. So they offer the power of regular testing frameworks.

Thus, `where` is the bonus, not a "compromise".

mercurial12y ago

This might work better for pure functions. I can't imagine it working very well for complex, stateful code which requires mocking and resetting the state between tests.

tel12y ago

Given that Pyret is functional, there's a good chance there will be an emphasis on simple, pure functions.

Beyond that, I'd agree completely. Doctests, for instance, are quite terrible when you can't fit all of the logic into one line, but then I think it's usually a sign of a well-designed function when it's good a good enough interface to get a few pithy doctests in.

1 more reply

skrishnamurthi12y ago

This is why a test block is a block. Writing inline tests for stateful functions in Racket was a bit painful because it is so heavily expression-oriented. We want to make this feel more natural.

(Another virtue of test blocks: you can write little local helper functions. There's an example of this on the Pyret home page.)

acjohnson5512y ago

They didn't say one way or the other whether the language was pure FP, but I don't think any of the examples featured mutuality

1 more reply

anaphor12y ago

Have you thought about adding some kind of QuickCheck-ish model where test cases can be randomly generated for various types?

skrishnamurthi12y ago

Yes, of course, we've thought about it. Equally importantly, we have a "satisfies" keyword for stating checks about properties. (See the example on the Pyret home page.) We use test oracles extensively in teaching; see these two assignments: http://cs.brown.edu/courses/cs019/2012/assignments/sortacle , http://cs.brown.edu/courses/cs019/2012/assignments/oracle .

tel12y ago

This exists in Haskell's doctest library

    -- | Documentation goes here
    --
    -- > 2 + 2 == 4
    -- True
    --
    -- prop> \lst -> reverse (reverse lst) == lst

ducklord12y ago

> Yesterday a lead programmer at a major financial institution told me that he liked that style so much, he'd incorporated it into his company's OCaml system, and they use it in their production systems (lots of high-volume trading).

Hmm...Jane Street?

j / k navigate · click thread line to collapse

0 comments

9 comments · 1 top-level

skrishnamurthi12y ago· 8 in thread

Nevertheless, perhaps you could provide some pointers to the "many" projects that have tried it before?

Assertions are not tests. This is a fundamental misunderstanding of the difference.

Pyret's `check` blocks exist to write complex tests, separate tests from definitions, or write tests that cross multiple functional units. So they offer the power of regular testing frameworks.

Thus, `where` is the bonus, not a "compromise".

mercurial12y ago

This might work better for pure functions. I can't imagine it working very well for complex, stateful code which requires mocking and resetting the state between tests.

tel12y ago

Given that Pyret is functional, there's a good chance there will be an emphasis on simple, pure functions.

1 more reply

skrishnamurthi12y ago

This is why a test block is a block. Writing inline tests for stateful functions in Racket was a bit painful because it is so heavily expression-oriented. We want to make this feel more natural.

(Another virtue of test blocks: you can write little local helper functions. There's an example of this on the Pyret home page.)

acjohnson5512y ago

They didn't say one way or the other whether the language was pure FP, but I don't think any of the examples featured mutuality

1 more reply

anaphor12y ago

Have you thought about adding some kind of QuickCheck-ish model where test cases can be randomly generated for various types?

skrishnamurthi12y ago

tel12y ago

This exists in Haskell's doctest library

    -- | Documentation goes here
    --
    -- > 2 + 2 == 4
    -- True
    --
    -- prop> \lst -> reverse (reverse lst) == lst

ducklord12y ago

Hmm...Jane Street?

j / k navigate · click thread line to collapse