 So, welcome everyone again. My name is Matthew. I'm a PhD student, so basically I'm not from the web community at all. I'm mostly doing MATLABs, scientific stuff. So I came to the Elm Realm, I would say, because I wanted to do a user study, just evaluating different kind of interfaces to do some image processing and things like that. So I needed a web page to do my user study so that people can access it. So I just say why not doing it Elm, because I don't really know JavaScript and I don't want to learn a lot of JavaScript, so anyway. So that's a bit of my background. The reason why I'm presenting how to use tests in Elm is not because I like it, though tests are important. But if you didn't know, on the meta page we gave a link and actually I could have presented a few different things and it was the one that was most wanted, I would say. So maybe next time I will redo the list without the testing and you can choose whatever you prefer to, which I can present. So about tests, first, why do we want to test things? I will start with a quote that is on the official Elm website. So I let you read the quote, impressive. So I think it's basically what every organization trying to use it in production is thinking. When at least if it's in the bound area of what Elm is good at, if it's outside of what Elm is good at, it tends to be a bit complicated. But if it's to do web application, super web application, it's perfect. So when you see that, you say, okay, I don't need testing. Everything works. No, no, any, I don't know, runtime errors. Yeah, actually, not exactly like that. But you still don't have runtime error, but we are whole human. So we make errors that are not types error, just logic error. So that's usually why you want to make tests. So but a bit a step back from testing, especially testing. From the user point of view, so you are a user, you want to use Elm code from someone else. I think these are the four most important things that you have to think about. So what can you do with the code that you are trying to use? How does it work? So is there a good documentation explaining how it's working? Is it reliable? So do they show some kind of build or test status? Do you think you can base your own code on this one? And eventually, if you like it, and if you find that you reach some limits, can you contribute to this code to improve it or develop any other functionality that you need? So this is a bit from the user point of view. And from the other point of view, the people that are building the libraries, usually you are building the library because it's useful or because it's funny. I don't see of any other reason, maybe because you want to get rich if it's somewhere. But I'm not sure Elm is the place for now. And you are thinking about two things. Is it reliable in a way that will other people trust your code you are doing? Or is it easy to contribute from other people? I mean, are you going to do it all alone every time? Or can you attract people to help you working on what you are doing? So especially for those two last things, testing is very useful. So I'll say this. Test helps building both trust and a community because it helps people contribute to your project. OK, so now that we know we want to do testing, how do we do testing? I won't go into details about a lot of codes. Maybe I will add a few codes at the end, but mostly these will be experiences. I wanted to mention this. So I've not done testing a lot in my Elm coding, but I've done a lot of examples. So I wanted to ask a question to the community. What are the best practices to make an example for when you are creating a package? And this guy, Noah, his name is known by his nickname. This guy, sometimes I don't understand this guy. He wants to help everyone. He's probably the first to answer a new user question on the Elm different way of communicating. But when you're doing something a bit wrong, sometimes it's here to hit you with a hammer and telling you, I know. So I had this question and all the answer was telling me, don't do examples, do tests. So do tests in those forms. So if you want to add examples in your documentation, just use Elm doc tests. So it's like examples when you give the answer of the code you are giving in the documentation, but it will generate tests that you can check so that the documentation never go unsync with the modification of your code when you are doing modifications. You want to have a test suite. So this is to test mainly the most important features of your code, and especially this is what is useful when you want other people to contribute to your code. And if you are views, you can even test the views. Like there is a library, it's called Elm HTML test. You can test basic stuff. It's more complicated to test a lot of events, elements when things happen after the orders, but the basic static views are easily testable with this framework. So basically, there is an Elm testing package for everything. So for the documentation, Elm doc tests, for your main tests, Elm tests, and for the view tests, Elm HTML tests. And the three of those are based on this one, which is a community-driven package so a lot of people have the view Elm HTML tests. It's basically you create a classic view, HTML view, and after you check with some functions that an element inside exists, that it has such property, et cetera, et cetera. I have a small example of the Elm. It's the last slide. So if you still have a question after this, do you have any other questions now? No, it's okay. Okay. So here we come to the part where there is a bit of code. So you have already been introduced to the type notations of functions. So I've been working with a guy that is doing a lot of geometric stuff to draw geometric figures in web pages. And there is this function that creates a line segment along an axis from one point to another. So that's what this function is doing along. I think it's pretty straightforward to see what it's doing. So you start from the first point that goes from the starting point and you go to the ending point of the line and it creates a segment. So this is the way you write documentation in your code. I think the syntax is similar to Haskell, I'm not sure. So the idea is that you describe small things, what your function is doing, and then you add examples. And examples are just one indented code. So if you write it this way with the three right-angle thing, you can generate doc tests with this. Actually, the syntax is going to change very soon, like tomorrow or something like that. So it's not going to be this anymore. It's going to be as if you write a normal code. So this will be a normal code. And this, which is the answer of this, will be like a documentation. So simple line documentation starts with a two union thing. So dash, yeah, dashes, yeah. Do you know why is this syntax evolving? I think it's because this is the first syntax the guy initialized when he started the project. I think it comes from Python or I'm not sure. Yeah, but the idea of changing the syntax here is that now if it's changed, it will look exactly like Elm code. So it will be Elm code here, but it can be interpreted and generate doc tests. Because if you remove this, this is just a call function in Elm. And if you add comments in front of this, this will just be a comment. So this can be executed exactly like this as an Elm code. Yeah, yeah. Yeah, and it's a convention that most people are using right now because this is quite recent and not many people are using it. So it's very simple to generate doc tests. You have to install a few things from NPM, which is the node package manager for JavaScript if you ever use it. So you have to install M test, which is the thing that all these free libraries are based on. You have to install M docs test, of course. And then you just initialize in some repository where you have your Elm code. It will create a test folder and you create an Elm doc test.json file. And you just say which of your modules contains documentation tests. And it will parse the documentation and generate files. Is there any modules that generate it automatically? I don't think so. I know that Elm test is working automatically. Yeah, Elm test is working automatically. But I don't know whether that will maybe roll up into this later. Yeah, maybe. But for now it's manual. So you run it like this, Elm doc tests. So it will generate the different files that will then be used by Elm tests. So this will generate this file that you test with Elm tests. So Elm test is the main tool. Okay, so how did I come to Elm tests? So I was telling you that I'm doing some image interaction stuff. So this is from a user study I did where we evaluate different way of showing things in an image and identify, we call this segmentation in the language. So the idea here is people could just draw an outline around the thing. And if we wanted to do this user study completely unsupervised, we need to have some things to make sure people are not doing anything crazy with the outlines. So for example, there was this check that I have that the outline is not crossing itself because it means usually people are doing bad things. So for doing all this, I was using the library of this other guy, which is Ian McKenzie. His library is called Opensl Geometry. It's mostly geometric stuff to the N3D to manipulate. Right now there is only an SVG rendering. He's working on a WebGL rendering also. And he has, I think I've seen ports to Haskell, maybe not PureScript, but I think he's doing PureScript also, how do you say, Microsoft Fsharp. So a few things. It's very cool. So I use his library and I saw in his GitHub that he was looking for implementing an intersection of different things like line intersection. So I just asked him if I could implement it because I've already done it with the outline things. And there started our discussion. So why do we need a test to do this? Mainly because it can be complicated. You think that line intersection is relatively easy usually, but we are dealing with computers, not humans. So there are a lot of things that may happen like infinitesimal errors in computing and things like that. So in a case like this, if you want your code to be reliable, like you want to make sure this point of this part of different segments is always on the top or on the bottom. It's very complicated to specify such a thing in a language. So we had to make a lot of different things. And the way we did it is mainly by imposing different tests that he wrote. We discussed different things. So Ian wrote these tests and he told me, okay, you can write your code, but we will have to make sure all those things happen. So for example, intersection is symmetric. So if you make an intersection of one segment and this second, it must be the same results that if you inverse the arguments, the first one becomes the second. So it's a lot of things, but you have to make sure that those things work and it's not always very straightforward. So Elm tests. So as you mentioned before, Elm test is automatic. It basically looks for every module that is in your test folder. So for example, in our implementation of the intersection of line segments, it was in a line segment 2D.elm module and it searched everything that is exposed and everything that is exposed, it tries every test inside it. So the head of the file in which you put the tests is something like this. So it imports a lot of stuff, the library you need to use and also those, so these are the library I need to use and also those three modules. The main modules is this one, tests. And it works with expectations. So usually when you specify tests, you expect a result from a computation. So you say this computation should be this or shouldn't be this or should be more than this or less than this, etc. So all this happens in the expects module. And the fuzzy testing is a bit different. Have you already done fuzzy testing? Who doesn't know what is fuzzy testing? No? So just to recap, fuzzy testing is to try different kind of configuration of testing automatically so that you don't have to specify every test manually. So for example, if you want to test that the sum of two ints is always the sum of two ints, you can make fuzzy testing and it will try with weird values that you may not come up manually to check that everything is okay. So it's just, yeah, to generate automatically. So property-based testing or so. I think I'm not sure if that's what you do. I'm not sure either because I don't test in my lab. It mostly breaks. So the test looks like this. So these are the two main functions that you will use. Test the test. So it takes a description and it takes an expectation. So this is just to say that just look at the expectation and it generates a test. The test will be passed to the runtime elm and it will verify that everything works. And the fuzzer is, you use a fuzzer. So if one of your variables of your test is an int, for example, you will generate a fuzzer of an int. So it will generate different int values. Then the same as the test. So description, the kind of things that you are generating for the test, expectations, and the test. So it looks a bit like this. For example, intersection is symmetric. So we have the same results. You start with a test.fuzz. So it fuzz two here because you have two arguments actually. So one segment, the second segment, the description, and then you expect something equal from the two segments. So you expect that the intersection of the first segment of the second is the same that the intersection of the second and the first. So it generates a test. And then the tests are automatically run by this command on tests with the folder with all your modules. So you can set up everything in Travis. I will not explain everything here, so you have all the things online. So you can set up and verify when people make pull requests on your code and things like that that it automatically runs the test and verify that it didn't break anything. So just so that you have an idea. So this simple intersection of two segments, it took 124 lines of code, mostly because there are lots of spaces in Elm, and those lines of tests. So tests are important and don't forget them when you want other people to contribute to your code. So HTML tests to test the views as before. So it's basically the same thing. You have all those requirements. You use the tests thing and you use HTML to generate HTML. So for example, this is a description of some tests. And here, you generate one HTML. So this part is the HTML you generate to generate a div that has a class container. And inside the div, there is a button with a text. And then you test this HTML you have generated. So it starts from this, then you have a different command like find the tag of a button and then verify that he has the property. In general, it takes this form. So you generate some HTML view and then you use query from HTML that transform the HTML message to something that is specific to the library. And then it takes this something specific to the library and you can transform it, like verify that there is an element inside or something like that. Check for an element or check for multiple elements inside. And then once you have done those checking, you verify a property of the striking. So the third type is verification. There are lots of different functions. So here we use the has verification that verifying that something exists but it could be anything else. You can check the library. And that's pretty much it. Okay, do you have any question? Have you tried them? You said you haven't used them much. Have you tried them? I've used the Elm tests library, and I've tried this afternoon. How did you find the sort of feedback from it? You need to figure out what is going wrong when you're just failing or how does that part work? Yeah, I think it's a bit scary at the beginning because it's a lot of code. When you look at this, you feel like there is too much thing and this is the simplest example I found. Most of the examples are too long to fit in this page and too long in line. But once you get the idea that you want to compare things, I think it's easy because when you run the tests, you have a recap, how do you say that? It's formatted in a way that, you know, a file, not a file, but you see in the terminal with all the green and red things. And it says exactly to you that this test with the description you've given isn't working because you wanted those things to be equal. So this message will change depending on what you use it. And the first thing is blah, blah, blah. And the second thing is blah, blah, blah. And you have the seeds that generated this wrong example. So you can get the seed and reuse this seed of random values to check that you have corrected the bug. And once you have corrected the bug, you just reset the seed to be random and go again, do some coding. So I think it's pretty straightforward when you get it. But it took me something like one or two days to understand a bit how it was working. But after that, it's okay. Any other question? Thank you very much. I think the different presentation will be available. Yeah, we'll probably put links.