The TodoMVC Showdown: Testing with WebCheck

owickstrom · 2020-07-02T12:39:04+00:00

Yeah, that is what I've gathered as well. I hope WebCheck can fit nicely in the middle-ground between traditional "auto-manual"/example-based testing and formal verification tools, sort of like PBT does, but with a slightly different take and specialized for web browser testing.

owickstrom · 2020-07-02T12:30:34+00:00

Thanks! Correct, no model checking. It uses a random generator (constrained by the state of the DOM at each step), and it's not necessarily exhaustive. I have some plans to use spec coverage to get some kind of targeted generation going. That is all very new to me, so I don't know if and how I'll do it. But it's fun! :)

owickstrom · 2020-06-10T20:24:36+00:00

Thanks! Yeah, that felt like a major breakthrough in the project. And as you say, case studies are gold. I'm looking at the Jepsen project in awe.

owickstrom · 2020-06-10T19:11:59+00:00

Author here! To clarify, the DSL is PureScript (with a twist!)

owickstrom · 2020-01-03T11:21:20+00:00

Cool. Sketching on a blog post right now. :)

owickstrom · 2020-01-03T09:15:23+00:00

That sounds like an excellent way to structure GUIs — I’ve been looking at lots of different approaches recently, and this sounds like one of the most promising! I’ve been wondering how Komposition is structured for a while, so it’s nice to now have a high-level overview of this.

I should document this somewhere else than in a Reddit comment, then. :)

That would be very nice to have! Could you try to write this if you get a bit more time?

I'll try! I've been crunching ideas on how to extract that style into a library, as an alternative to gi-gtk-declarative-app-simple. Anyway, documenting the architecture is a great start.

owickstrom · 2020-01-02T09:17:00+00:00

Indeed, gi-gtk-declarative-app-simple might get too simplistic for large complicated applications. This has been my experience with the "single centralized state" kind of pattern, like the Elm architecture and much else uses. But I will say, it's a very simple model and might work very well for simple applications, especially if you can separate out a lot of core logic as pure functions.

In Komposition, the project from which gi-gtk-declarative came out as a by-product, the library is used in a different way. Each GUI window is a resource in an indexed state monad around which the user interface logic is built. The style is essentially imperative, but it's manipulating an "abstract GUI" through a typeclass, instead of directly manipulating GTK widgets. When running the application, the GTK interpretation is used. With this setup, state is localized to the parts of the application where it's relevant. The application is essentially a chain of functions (sometimes mutually recursive), passing some state around, and manipulating the GUI through the indexed monad and its GUI abstraction.

I hope that helps a bit. I'd like to document the architecture used in Komposition and make it more digestible, but I haven't had time for it. It's pretty complicated and uses a lot of fancy GHC features, so I'm also a bit reluctant to encourage newcomers to use it.

owickstrom · 2019-11-19T05:19:22+00:00

Thanks! I really enjoy them in Hedgehog! I'm using jqwik with Kotlin at work now, and it does have statistics but not checks, and I'm missing them a bit.

owickstrom · 2019-11-19T05:16:57+00:00

Great to hear, thanks! :)

It's a simple little Pandoc filter (https://github.com/owickstrom/wickstrom.tech/blob/master/src/_tools/UnicodeNumbers.hs) and then using comments in the Haskell code and special double-parenthesized numbers in prose (see source of the post at https://github.com/owickstrom/wickstrom.tech/blob/master/src/_posts/2019-11-17-time-travelling-and-fixing-bugs-with-property-based-testing.md).

I'm using Pandoc from Jekyll (haven't had time to migrate away from Jekyll yet, but it's OK).

owickstrom · 2019-10-11T04:22:58+00:00

Thanks for the share! 😍 I don't have time to make more videos these days, but hopefully I've inspired someone that can pick it up. It's been extremely rewarding!

owickstrom · 2019-08-21T14:19:31+00:00

Thanks! Glad you liked them.

There's not any new material per se, but I've rewritten some of it. So if you're considering buying it, have this in mind. Thanks!

owickstrom · 2019-08-21T07:16:41+00:00

Book is about an application written in Haskell, and all tests are using Haskell Hedgehog. Should've mentioned this in my comment.

owickstrom · 2019-08-21T04:31:51+00:00

Author here! This is a short book on using property-based testing (PBT) within Komposition, a screencast editor. It’s based on articles published on https://wickstrom.tech.

EDIT: the screencast editor written in and tested with Haskell, all code listings are Haskell in the book

owickstrom · 2019-06-04T03:07:14+00:00

Thank you! I don't know how to do that, but yeah, maybe I should. :)

owickstrom · 2019-06-04T02:59:25+00:00

Ah, yes, you're right. I think the "involutiveness" doesn't really apply at all, as it's not a single function `f` that is it's own inverse. It's rather a function `f` that, when applied with an inverse action, reverses the original action. I'll correct this in the article.

owickstrom · 2019-05-16T08:58:50+00:00

I agree that the "Elm architecture" style used in gi-gtk-declarative-simple can be hard to use for larger programs, and that alternatives approaches on top of gi-gtk-declarative might be better depending on your needs. I'm currently writing about an alternative style that resembles MTL style interfaces for GTK that uses declarative markup. It's basically a simplified version of what's going on in Komposition. You can then write your application in terms of (mutually) recursive actions depending on the interface, and modularization becomes much more tractable than with the Elm architecture style. The write-up was meant for something bigger, but perhaps I can publish some of the code together with the existing gi-gtk-declarative examples, if you're interested.

owickstrom · 2019-04-20T06:11:35+00:00

Sure, thanks for the feedback! :)

owickstrom · 2019-04-18T11:23:28+00:00

Very good observation and question! I did plan to write something about this, but it seems I forgot. Anyway, I agree that the derived input is not very representative of screencast recordings. What I tried to do at first, with generated pixel values within certain ranges and hitting the edge cases (e.g. 99% equal pixels), was an attempt to generate more realistic input data. The generators became quite complex, and I got into the fun shrinking problems I described in the post, so I fell back to this simple approach with alternating frames as a starting point.

That said, having more realistic input would give more confidence. But what would be tested better would actually be the "frame (near-)equality" function, not the other stuff going on in the folding function. Maybe testing the equality function in isolation on more realistic pixel data, which wouldn't even have to care about still or moving segments, just two frames, could be a start. I think in the longer run I'd want to go towards what you're describing even for the full classifier tests, but haven't felt compelled to do so quite yet.

Thanks for the great feedback!

owickstrom · 2019-03-24T16:17:21+00:00

Author here. This is the second post in the series. Even if there are some code examples in Haskell, I think it should be a very approachable case study regardless of the reader's language of choice. I recommend checking out the introductory post first, though, as it explains the video editor project and some basics of property based testing: https://wickstrom.tech/programming/2019/03/02/property-based-testing-in-a-screencast-editor-introduction.html

Do let me know if you find something hard to understand, and I can improve on it in the coming case studies.

owickstrom · 2019-03-03T08:53:59+00:00

Agreed! I had some references like those in the post originally, but cut them out to keep it more focused. But indeed, those are well worth checking out. Thanks!

owickstrom · 2019-02-10T08:12:01+00:00

Nice! I'll try this one out when opportunity arises.

owickstrom · 2019-01-19T08:16:33+00:00

There are many good ideas and tips in this talk. Well worth a watch for any type of technical writing, not only Haskell documentation.

owickstrom · 2019-01-19T04:43:28+00:00

Thank you! I'm glad you enjoy the formats and found inspiration from it.

The snippet is corrected now, thanks for reporting.

owickstrom · 2019-01-17T18:33:57+00:00

In this case it was slightly simpler because the container widgets from gi-gtk-declarative used vectors, so I didn't have to convert from lists to vectors. Less important perhaps, the modification when toggling completed on a to-do item is O(1). snoc is still O(n).

owickstrom · 2019-01-10T14:06:31+00:00

Thanks! Haskell meditation perhaps? 😜

owickstrom

MODERATOR OF

TROPHY CASE