5 ms·

So, as someone without too much experience in language development, the concept of having unit tests being an extension of the functions themselves seems very i

by eykanal 10y ago

So, as someone without too much experience in language development, the concept of having unit tests being an extension of the functions themselves seems very interesting. Clearly this doesn't work for all scenarios—multiple functions interacting, any sort of GUI interaction—but that's a very intriguing concept.

dexwiz 10y ago
Agreed. It probably helps enforce pure functions, which are one of the big pros touted about functional programming. Ideally most functions should be pure and isolatable from the rest of the program.
jstimpfle 10y ago
Is there something that prevents you from making functions that only check how other functions interact?
- eykanal 10y ago
  No, not at all. The point is that there's specific syntax in the language for making this part of the function definition, as it were. New concept for me.
- Avshalom 10y ago
  Scoping rules probably get in the way in some cases.
- deleted 10y ago
  [deleted]
Jtsummers 10y ago
They have a check clause which is detached from the functions themselves. This is where they would want you to do tests with multiple functions interacting.
thom 10y ago
I've written a lot of tests using Clojure's with-test, which is slightly less elegant, but the same style: https://clojuredocs.org/clojure.test/with-test https://clojuredocs.org/clojure.test/with-test I've found it wonderful and productive for low-level bits of functionality, especially working on small data structures and primitives. With Emacs set up to reload the namespace and run all the tests on every save, it's a great feedback look with very little cognitive overhead. It breaks down a bit for more involved tests, as you say, and it can be taxing knowing when to refactor, how much test setup code to include along with the unit under test, and also once you start splitting things into other namespaces, where to look to get a full view of a module's functionality.
GoodieBear 10y ago
I agree
sergiotapia 10y ago
It's pretty awesome. This is the feature that stands out to me for Pyret. Also see how Elixir does it: http://elixir-lang.org/getting-started/mix-otp/docs-tests-and-with.html http://elixir-lang.org/getting-started/mix-otp/docs-tests-an...
skrishnamurthi 10y ago
Actually, it does work for interaction if you program interactions Pyret-style, which effectively separate model from view. Models are updated functionally, so it's trivial to write tests for the model-updaters. Animations and games are obtained by having the underlying event loop infrastructure automatically compose these functions. This is the same methodology we use in Racket and in the Bootstrap curriculum [http://www.bootstrapworld.org/ http://www.bootstrapworld.org/].
mpweiher 10y ago
My MPWTest[1] Objective-C unit testing framework has unit tests as categories of the class under test. For me it - avoids the duplicate class hierarchies you get with xUnit, - avoids having to expose class internals for testing, - makes tests an integral part of code, instead of an external add-on. [1] https://github.com/mpw/MPWTest https://github.com/mpw/MPWTest

by eykanal 10y ago

dexwiz 10y ago

Agreed. It probably helps enforce pure functions, which are one of the big pros touted about functional programming. Ideally most functions should be pure and isolatable from the rest of the program.

jstimpfle 10y ago

Is there something that prevents you from making functions that only check how other functions interact?

eykanal 10y ago
No, not at all. The point is that there's specific syntax in the language for making this part of the function definition, as it were. New concept for me.
Avshalom 10y ago
Scoping rules probably get in the way in some cases.
deleted 10y ago
[deleted]

Jtsummers 10y ago

They have a check clause which is detached from the functions themselves. This is where they would want you to do tests with multiple functions interacting.

thom 10y ago

I've written a lot of tests using Clojure's with-test, which is slightly less elegant, but the same style: https://clojuredocs.org/clojure.test/with-test https://clojuredocs.org/clojure.test/with-test I've found it wonderful and productive for low-level bits of functionality, especially working on small data structures and primitives. With Emacs set up to reload the namespace and run all the tests on every save, it's a great feedback look with very little cognitive overhead. It breaks down a bit for more involved tests, as you say, and it can be taxing knowing when to refactor, how much test setup code to include along with the unit under test, and also once you start splitting things into other namespaces, where to look to get a full view of a module's functionality.

GoodieBear 10y ago

I agree

sergiotapia 10y ago

It's pretty awesome. This is the feature that stands out to me for Pyret. Also see how Elixir does it: http://elixir-lang.org/getting-started/mix-otp/docs-tests-and-with.html http://elixir-lang.org/getting-started/mix-otp/docs-tests-an...

skrishnamurthi 10y ago

Actually, it does work for interaction if you program interactions Pyret-style, which effectively separate model from view. Models are updated functionally, so it's trivial to write tests for the model-updaters. Animations and games are obtained by having the underlying event loop infrastructure automatically compose these functions. This is the same methodology we use in Racket and in the Bootstrap curriculum [http://www.bootstrapworld.org/ http://www.bootstrapworld.org/].

mpweiher 10y ago

My MPWTest[1] Objective-C unit testing framework has unit tests as categories of the class under test. For me it - avoids the duplicate class hierarchies you get with xUnit, - avoids having to expose class internals for testing, - makes tests an integral part of code, instead of an external add-on. [1] https://github.com/mpw/MPWTest https://github.com/mpw/MPWTest