 Je m'appelle Christian Coudaire et je vais parler de la gîte et de la testée. Comme vous savez, la gîte est un système de contrôles distributifs. Elle a été créée par Linus Torvald en avril 2005 et elle a été maintenue par Junior Hamano depuis juillet 2005. Et c'est maintenant le système de contrôles plus populaires. J'ai commencé à travailler sur la gîte en 2006 en mon temps libre. J'ai travaillé spécialement sur la gîte Bisecht et maintenant, depuis l'année dernière, j'ai travaillé comme consultant indépendant et développeur pour Booking.com, la gîte et les protocoles. Donc pour Booking.com et la gîte, je travaille sur la gîte mais pour les protocoles, je travaille sur quelque chose qui s'appelle l'IPFS. Est-ce qu'il y a des gens qui connaissent l'IPFS ? Oui, il y a très peu de gens. Donc je vais vous parler un petit peu de ça parce que mon parler est sur comment j'ai utilisé les features testées ou les features testées de la gîte pour développer l'IPFS et aussi comment il est utilisé pour développer la gîte. Donc l'IPFS est appelée par la web permanente. C'est un protocole d'adresse de contenu qui est un petit peu comme HTTP mais il a des features de gîte et de biturant, et c'est un software half-ass en go. Et comme gîte, il a un interface commun-line et ce que ça signifie, donc gîte est aussi adressée pour contenu qui signifie que vous retirez des contenus en utilisant un hash de contenu. La web, c'est-à-dire que HTTP est adressée en location parce que un nom comme exemple.com est transmis dans un IP adresse qui est une location. En IPFS un nom comme exemple.com est transmis dans un hash de contenu et puis le protocole a essayé de retirer les contenus d'où il peut trouver. Donc quand j'ai commencé à travailler sur IPFS il n'y avait que des tests unis, pas de tests de black box et c'était sous développement et il y avait beaucoup de régulations parce que chaque développeur avait une partie sur sa partie et ils étaient basically improving leur propre partie du code mais ils avaient fait des choses pour l'autre tout le temps. Donc il a vraiment besoin de tests de black box Donc, comme je savais que gîte j'ai décidé d'utiliser le framework gîte pour tester l'IPFS comme un black box. Le framework gîte a été développé par Junior Hamano en mai 2005 donc juste un mois après qu'il a commencé et il s'est développé en Shell et il a été extracté 5 ans auparavant par Matthias Lafeld dans un projet qui s'appelle Charnes et en ma opinion c'est l'une des raisons pourquoi le gîte a toujours été très stable c'est parce que c'est vraiment compréhensible et il a testé beaucoup de choses Donc, comment testes-tu avec Charnes? Si c'est un script shell tu as les trucs de hashbang puis tu as donné un titre avec un exemple de Charnes tu sources le library de Charnes et puis tu as choses comme test-expect-success ou test-expect-failure et donc chaque test a un nom et il a des commandes comme celui-ci qui sont liées ensemble avec double ampersons donc si, de cette façon, si les commandes failent, le test va failer et puis à la fin, tu dois utiliser test-done et tu peux ramener comme ça donc peut-être que tu peux voir un exemple non, pas ici donc ça ressemble à ça et comme c'est un script shell tu peux juste, quand c'est comme ça je peux ajouter autres tests comme, je vais juste donc j'ai ajouté un autre test à la fin donc maintenant, si je ramène encore, il y a deux tests et il y a des bonnes features comme par exemple pré-requisites parce que parfois, tu veux seulement faire des tests et quand des conditions sont satisfaites par exemple tu peux avoir des tests expensifs qui rèvent pendant longtemps que tu veux rèver seulement parfois et aussi, à la fin, quand tu rèves tous les tests tu peux aggreger tous les résultats de tous les tests comme ça donc ici tu peux voir que la plupart des tests ont réussi personne n'a failé mais il y a des blocs il y a des blocs qui sont attendus à fail en fait et des fixations qui sont attendus à fail mais qui ont réussi parce que comme je l'ai dit il y a des tests tu peux utiliser des tests à fail quand tu as des tests à fail parce que des bugs ou des features qui n'ont pas déjà été implémentées oui, donc ce sont tous les features bien, des features de Charnes donc c'est vraiment facilement extensible et tu peux utiliser des outputts verbaux par exemple ici je dois juste passer minus v et j'ai un plus détaillé outputts tu peux aussi avoir failé immédiatement si un test a fail et tu peux utiliser des tests à fail dans les tests pour que ça ne stoppera et tu peux débarquer ce qu'il y a et aussi, si l'outil est dans le test à fail tu peux utiliser beaucoup de choses beaucoup d'outils par exemple il y a un outil qui s'appelle Prove c'est la même output mais je ne sais pas si tu sais que tu peux tester quelque chose un peu de gens ok je pense que c'est intéressant que c'est dans un outil standard donc maintenant ces jours l'IPFS a 58 tests scripts ce qui signifie à peu près 800 tests et ils sont automatiquement de chaque comité de chaque call request à peu près que l'idée je pense qu'il y a un outil comme ça parfois, mais on utilise Github et les outils comme Travis et CircleCI que l'on utilise ne fait pas vraiment facile d'avoir tous les tests sur chaque comité mais on a utilisé des tests et je pense que on va le faire plus vite et on ne voit pas les tests sur les windows mais on travaille et ce qui est intéressant de cette expérience et je pense que beaucoup de gens dans la communauté Github et spécialement et aussi la communauté Linux ont cette expérience que c'est vraiment bon d'avoir des tests black box pas seulement les tests unis et aussi la compétibilité de breakdown c'est vraiment mal pour même pour pro alpha software parce que vous vous break expectations pour vos utilisateurs pour vos testers et ça a été très mal donc les régressions sont toujours en place parfois parce que les tests ne peuvent pas couvrir tout pour ça on utilise Github et on parle de Github et pour vérifier que chaque comité doit passer tous les tests on utilise des choses comme ça donc je ne sais pas si quelqu'un sait ce que ça fait donc je vais vous montrer peut-être maintenant oui donc on va essayer de faire ça c'est un peu plus complexe que ce qu'il y a sur le slide donc on va voir ce que ça fait si vous savez la base interactive Github la base Github vous donne quelque chose comme ça vous avez un pique à l'enceau du début de chaque ligne 1 et ici après chaque ligne vous avez un alignement de la ligne ce que ça va faire est que Github va l'uniser la première comité et ensuite exécuter la commande basque Alors, on va retourner à la, oui, je peux juste rentrer pour maintenant. Donc, si je dis ça, vous voyez que c'est rentrer, c'est rentrer la commande de Make, ici, parce que c'est une pièce de rébuildement, après avoir un grand cherry-pick, le premier commit. Donc, je vais retourner à ça plus tard. Maintenant, let's have a look at Git bisect. As you know, Git commits form directed acyclic graph. So, that can be shown like this. So, the history direction is from left to right. So, commits are pointing to their parents. And you can see that some of them have many parents because they are merge commits. And the idea behind Git bisect, by the way, how many have been using Git bisect already? Yeah, a lot, that's nice. So, the idea behind Git bisect is to find the first bad commit, what we call the first bad commit, which is the commit that introduce a behavior that is usually a bug or a regression. And as you can see, all the commits that are descendants from the first bad commit have also this bug, let's say. So, yeah, and we are using a binary search algorithm for efficiency. And the benefits, if we find the first bad commit, is that it's much easier to check what happened in the first bad commit instead of the whole source code because usually commits are quite small. Well, they should be. And the commit also gives extra information like commit message, author, date, and so on. So, you can start it. There are two ways. So, you can just say Git bisect start and then give the bad commit after Git bisect bad and the good commit after Git bisect good. Or, you can just say Git bisect start and then give the bad commit and the good commit. So, because, well, most of the time, you know on which commit it failed and which commit it was good. So, after you do that, for example, like this, it tells you that there are some revisions left to test and some number of steps and it checks out automatically a commit that you have to test. So, then you test this commit and you say whether it's bad or good using Git bisect bad or Git bisect good and it checks out another one and so on until you find the first bad commit. So, here it was a toy example where I just tried to find the first commit that introduced 26 in the version number. And so, when the first bad commit is found, so, you can take a look at it and play with it and after that, you have to use Git bisect reset to go back to the branch from where you started. And the other way to bisect, so, previously, this was the manual way to bisect. You had to say to test each commit that Git had checked out and then say whether it was bad or good. But you can just use Git bisect run and give it a script that will be used to check each commit. So, for example, if you are bisecting a broken build, you can just say Git bisect run make and it will run make automatically at each commit to say whether it's good or bad. And, for example, with the previous toy example, I used, so, Git bisect start with those two versions, the bad one and the good one. And then, Git bisect run with this command. So, it grabs the make file to find to say whether sub-level equals 25 can be found in it. So, as you can see, it tells you that which command it is running, then which commit is checked out and so on. Automatically, and you find the, in the end, you find the same first bad commit. So, how does it knows after running each run command whether the commit is good or bad, it's with the exit code of the command. So, when it's zero, it means good. And most of the exit numbers from one to 127 except 125 are bad. 125 means that the current commit cannot be tested. And the other possible exit numbers are considered really bad so that it should, bisections should be stopped immediately. So, why are those kinds of, are those different kinds of exit code useful? Well, especially the skip one. It's because sometimes you have a lot of untestable commits. For example, what happened in IPFS development is that some people started to work on something. And what they did is that they created their own branch. They started to develop, they committed, then started, then developed a little bit more committed and so on. And after some time, they decided to check whether it compiles or not. And unfortunately, it didn't compile. So, what they did is that they just fixed the breakage and then they committed and then they sent the pull request. And so, of course, this is bad because if the pull request is merged as this and this was the case at the beginning, then you end up with a lot of commit that just don't compile. So, you cannot test them. So, in this case, Git bisect tells you something like this. Yeah, but it's not pretty. Because you really don't know what happened. So, there are ways around it like you could apply a patch automatically or not before each test so that you fix the compile, the build, and then you can test. Or you can just create a branch where all the compile errors are fixed, which is usually quite easy because if this commit fixed the compile problem then you can just perhaps squash it with the commit that introduced the compile problem here. So, you get a fixed up branch like this and you can bisect on this branch. And there is even something called Git replace that I worked on. And this is a way to tell the history that it should not go this way but this way. So, this is kind of a hack, but if you are interested you can take a look. So, now let's have a look at some demos again. Because I think that's probably quite interesting. So, here I just, yeah, it's not really. So, yeah, let's start with, for example, some tests we wrote for, I will show some features. So, that's the IPFS repo. And there are a bunch of tests, of Charnes tests, yeah. You cannot see it very well here because I had to, so these are all the test files. Let's look at one. So, what you can see here is, so here you can see some tests with a prior exact. And if I launch this, oops, yeah, there are some failures. So, I will just, because some tests are using fuse and there is some problem on my computer with fuse. But, yeah, so, I had something for that. So, here I will just export this environment variable and run again. And you can see now that the fuse tests are in blue, so they are not executed. Here you can see that some tests even have two prior exact, expensive and fuse. And if I want to run the expensive tests, I just need to append this, for example. And now it's only the fuse tests are not executed or skipped. And it takes a lot of time because here we are generating a 100 megabyte file. So, I will stop it now. So, running the tests is very simple. You just have to run make, for example, like this. It builds the binary first if it has not been built. And then it will run some tests like this. So, this is the same way as Git is working. If you, in Git, the test directory is called T. So, here you just, yeah, it runs tests also. And you can see there are some that are also not run automatically. Yeah, one interesting thing is to show Git by Sectron. So, I will show you. Yeah, so, here there are 10 commits. It's an example repository with 10 commits. Each one has just one line in a foo.txt file. So, it's pretty simple. I used this small for loop to create this commit. And now, let's say that I want to find... So, if you want to find which commit introduced some text in some files, there are other ways to do it. You can use Git log minus big S, for example, and I will show you. So, this shows that the commit that introduced 8... Yeah, I should have done it like this with the file name, but it's the same. Here, there is only one file. So, it is foo.txt. Yeah, if you want something a bit more verbose like this, this way. But, it's a good way to test Git by Sect. So, I will just use... So, I will find, I will say that the bad commit is the current one, the 10th commit, and the good one is the... I don't know if you know this kind of notations. Yeah, so this means that it's the 7th commit before head among the first parents. So, if you just do that, it will check out one commit in between, and then you can... Yeah, first you need a test script. So, I will just... So, this is a very simple test script. It just grabs for 8 in the foo.txt, and if it's found, we consider this is bad, so we just use false here. And when you actually run it, you see that it finds the same line, the same commit that introduced the 8 in it. So, you can see the detail. It's not so interesting, because it's very small, but... And after that, for example, you can do Git by Sect Reset, and you go back to where you started. So, my GitHub name is Chris Kool, and I became the Sharnes maintainer a few months ago, because Mathias Lafelt, who had created it, was not really interested in maintaining it anymore. And I also created something called Sharnesify, which is a shell script that helps creating, installing Sharnes into your code, because it's not... Well, the process is not really difficult, but IPFS is made of a big number of different repositories, and after I did it for a few of them, I just scripted it to avoid doing this kind of repetitive tasks. So, of course, you know the Git main URL. I also maintain... I'm also an editor of a Git newsletter called Git Revenues. So, if you go to this site, I forgot to edit, and you click to Git Revenues. Oh, well, let's see the archives. So, you see a lot of... So, there is one edition per month, and you can find articles and many other things about Git development. And, yeah, there are also developer interviews. So, for example, this is one guy working for Autodesk to improve Git LFS on the Git site, and other clean and smudge filters for those of you who saw Teams presentations this morning, if you are interested. And there are also news about releases, and about tools, and many other things. So, here. And I'm doing this with Thomas Ferris-Nicholaisen and with help from people from the Git development community. And that's pretty much it. I hope that you could see that it's really helpful to have black box tests, and that something like Sharnest can be very helpful. And that also it's very useful to check that each commit builds and pass the tests. Unfortunately, Git Hub, for example, and tools like Trevis and so on are not really pushing people into doing these kind of things. I think it's a bit unfortunate, but that's it. And, yeah, use Git bisect and automate it if you can. Now, I need to thank a lot of people. So, yeah, of course, Junior and Linus, and also people from the IPFS community, Juan and Jeremy, and Matthias Laffield for Sharnest. And thank you also to the LinuxCon organisers and attendants. So, thank you everyone. And thanks also to booking.com, GitLab, and Protocol Labs. The companies I'm working for. And now, if you have questions, yeah, my opinion is that if you have a command line tool, it's very useful because you really test like the user would do it. So, because basically a shell script is like someone using the command line. And also you can use all the other unique tools and pipes and so on. And I think it's much easier, a lot of time rather than doing some kind of pipes in programming language or something like that. I don't know if you have used something else. Oh, I was just wondering what the design decisions were behind that. Well, also, I don't know if you know it, but many Git commands have been developed as shell scripts. So that's why at the beginning, Junio used shell scripts for that, I think. Because basically if you wanted to develop Git, you had to know shell scripts as well as C, of course. But at the beginning, there was a really small number of core Git commands that were written in C. And most of the other ones were written in shell scripts. And there are still many commands that are shell scripts. Like Git bisect itself is half a shell script, half a C code. Well, there is a Google Summer of Code student working on porting, by the way, the Git bisect shell script into C code. I'm monitoring it, him. And also, yeah, there are other commands like Git rebase. It's easy to see if you go into the Git source code and you do this. You can see that Git rebase, for example, is a shell script that calls other shell scripts, by the way, and Git submodule, for example. And Git filter branch, which explains a bit why it's a bit slow. So, yeah. Are there other questions? Otherwise, you can just ask me, I will be around a bit. Thanks again, everyone.