Okay, welcome to the second talk. We have Moray Allen here, who will talk about paths into Debian, different ways of getting into Debian, and Moray is a long-term Debian contributor and currently one of the Debconf chairs. So enjoy his talk. Moray. Hi, so this is also meant to be a discussion, so I hope you can kind of wake up slightly and get ready to say some things as well, not just on RCE, either, maybe. So first, before starting off, I'd actually be interested to hear from a couple of people, or a few people, if they can say how they originally came, started doing things in Debian, or why they, I mean, if you're at Debconf, presumably you've had some contact with Debian. I don't know, can I volunteer someone, or maybe like Ashish or Margo, or someone else can say something if we have an audience mic? So I started using Debian around 2001, 2002, and I started just as a user, then I wanted to contribute more, but I didn't know how, so my first point of contribution was trying to create good bug reports, and so trying to be good at that, and starting doing some patches, and then I went to Debconf 4, and to me that was like a turning point in my involvement in Debian, putting faces into names, and I don't know, knowing the people that I was speaking to on IRC, knowing how they reacted, the way they acted, it made me much more comfortable in the Debian community, and I very quickly after that I started like, maintaining packages and doing a lot of other stuff. Ashish was good as hell. So I also began using Debian around 2001, and then I started, I mean, I evangelized Debian a lot to my friends, and they were surprised when I seemed to know what every package did, when they were just running it just upgraded, like what is the block ID to do, and around 2004 or so decided I want to contribute more to free software, not just projects that I started, and was trying to choose between contributing to Debian or Ubuntu, and chose Debian because it was an older, more community-based distribution, and the thing I did in Debian would flow into Ubuntu, and it has these goals of free software, and it's not written anywhere, but basically of being as excellent and perfect as possible, and so I found some random tools that had ITPs, RFPs, requests for packages that I could package, and those were pretty easy, and I found a sponsor by shaking the mentors list, I guess, and then I met Mako Hill, who became a friend of mine, through mutual friend, and then I started doing a lot more in Debian, and I started maintaining the Alpine mail reader, and then became a DDD, and somewhere along this, while not yet a DDD, went to a DebConf, and that also really made me much more excited about the project, so I guess I'll emphasize that's a seven-year gap from 01 to 08, with the activity really going up a lot starting five or six years in. Maybe someone, we can force someone hiding at the back of the room, I'm sure someone has, must have got to Debian somehow. Well, I remember the times when I was using this proprietary operating system, and well, I knew it quite well, but I didn't like it so much, so I read on mostly Usenet that there's this linux thingy, and I got curious, and reading Usenet postings, it looked like the cool guys are all using Debian, so I looked into Debian too. Well, and at some point I wanted to know how this is created, I started to read mailing lists, I tried to learn packaging, and well, and then some people helped me along the way, like sponsoring packages invited me to join teams, and since that time I really enjoyed being part of this social project called Debian, which creates an operating system. So, yeah, maybe just to be interested in who's here, how many people in the room think that they, well, how many people feel that they are currently contributing to Debian, I guess probably most people here? Or, and who is, who didn't put their hands up in the previous question? Okay, and out of people who are contributing, let's say how many people have been contributing up to two years, and then maybe kind of between two and four years, four and eight years, and eight to 16 years, and anyone in the room with more than 16 years? Probably they're in the bar. Okay, so maybe we can hear later on some more people's own versions of how they've got into Debian, but I'll just present a few things to say how the processes have changed a bit over time. So really the, well, if we had someone like Bdell here, if you haven't heard about from some, find Bdell in the bar later, and you can ask him how he got involved in Debian, say, pretty much in the early days of Debian, it just meant you sent an email saying, hi, I want to upload packages, and you got the FTP password, and that was it. Some processes started to develop over time later on, which kind of culminated in the famous NM, or new maintainer process as it was at the time, which itself then evolved over time and became a kind of feared by people as a big bureaucratic stage with, again, not necessarily the truth, but at least the perception from people was they needed to kind of write essays on the philosophy of free software, be some kind of carnal hacker, licensed guru, lawyer, everything else. And also it just, again, the perception rather than necessarily the reality was this took a long time to go through. In practice, at any stage, every time we've had the NM process, there have always been occasional people who had passed it in kind of one evening, a few miles backwards and forwards. But for most people, I mean for myself, when I went through NM, you get this, I got this huge list of questions which just seemed intimidating, and maybe I took a few weeks or a month or two to really get around to finding time to apply to it properly. And then the whole process then stretched out over a few months, which is pretty typical. Much more recently, as a formal process for getting into Debian again, people have created the so- called DM status, which is in a way, I mean some people will disagree with me for saying this, but in a way it's meant to be a kind of sticking plaster for the fact that NM was seen as difficult or slow. This is to say that just much more easily, if you were doing some work in Debian already, you could just apply for this status and be able to upload your packages without needing a sponsor anymore. Now, both of those are kind of to give people some formal status, but again, unlike when Debian started off, to be able to get any kind of formal status, you already need to be doing some work, which is really a kind of chicken and egg problem for a lot of people, that people don't feel entitled necessarily to do the work if they haven't got some status, but they can't get the status until they start. Our motto for this in Debian has always just been that there's no problem, people should come along and they should just start working on something, but if you're really new to the project and don't yet have a good social link, don't yet understand how things work, that can be quite difficult. The traditional way to get involved in Debian, as to be recognized as some kind of contributor, has been by doing packages. Traditionally, since the kind of time we had the new maintainer process, the way this has generally worked is to tell people, if someone comes along seeming interested in working on Debian, then you say, yeah, just adopt some package. You can just look at the WNPP, which is a list of packages that have been orphaned or the current maintainer is looking for replacement, maybe. You can look through that and find some package that you could take. A problem there, though, is that actually pretty often packages have been orphaned or are being orphaned for some reason. Sometimes, and often the current maintainer really knows, for example, the package is basically dead, the dead upstream maybe, there's not so much interest, but because they invested a lot of time in it over the years, it's hard for them just to say, we should kill this package. So they say, well, let's find some new victim to take this on. But it can be then dispiriting if you are the lucky winner of the new package, that you then find out you've got this package which no one's fixing bugs upstream, maybe it's becoming incompatible with other parts of the system, it's kind of out of date or problematic. So you see a lot of people who adopt packages and then maybe six months later or a year later, they haven't really changed much and they kind of find it difficult to move on from that. An alternative approach which, again, is a good approach in some ways, if you're interested in packaging, is just to find some software that isn't packaged yet and package it. But unfortunately, Debian is quite big now. So probably most of the software that a lot of people really want to use and that has a clear license and that is possible to package without going mad has already been packaged. So again, even a lot of software that maybe isn't packaged and seems useful, nowadays often it will be a web app. And the upstreams for web apps extremely rarely are interested in the idea of having them packaged. They think they should just make some huge, terrible U download which overwrites half your system and installs a few languages you hadn't heard of and plus PHP and MySQL and whatever else. So again, well, if you're really an advanced packager, you can try to kind of disentangle that all and make something clean. It's really a nightmare if this is your first experience of Debian packaging. So a kind of what people might be recommended to do more recently within packaging would be, say, to join a packaging team. But again, even in that there is kind of trouble because if you're not in the team yet and if you're not making contributions yet, say you turn up, even if you find where to speak to the current members of the team, maybe on some RSE channel, if you turn up and say, oh, hi, I've never done any Debian work yet. I don't know anything about packages, but I want to help. If you're lucky, they'll say, well, great, we'll mentor you. But in a lot of teams, there's likely to be a kind of lack of interest because they don't really have the time to mentor someone or they're worried that you'll just break something. It varies a lot between different teams, but again, there's no way easily to find out which teams will be receptive necessarily if you're just a new person who turns up. The other issue, so up to now, in the examples, I was talking about packaging, which has always been traditionally how we got people to be recognized contributors of Debian. But in the last few years, there's been much more recognition within the project that, yes, packaging is central to Debian, but it's not the only way that people should be working on it.  So one that has happened over the years often and has been very successful at getting new people involved in the project has been translations. Now, this is kind of seen as a success story because Christian took it on himself to push this a lot for Debian Installer and then through that to try and build up language translation teams for other areas of packaging. But, and then did active things like we've always had the exciting maps of the world showing coverage for DI, so there's a kind of game element or you can get your country, your language, higher up the list by helping out and so on. But even in translations, in the more general area, if you look at just translations of the upstream software itself, which is actually what users see most of the time, then we don't have any kind of, anyone leading the same kind of effort. So again, if someone comes to Debian as a translator, we can direct them to maybe help with DI or to help with Debian translations, other things like this, but there's still, it's kind of hard for someone who's just starting off. Maybe what they were interested in is actually having some piece of software they use a lot in their language or improving it. And again, even where there are existing translators, they like the packaging people, can be a bit territorial, that they have their own ideas about how you should translate technical terms into the language, for example. So if you come along with someone else with a different idea, then it can be hard to kind of get yourself in there and be seen as a useful contributor and to get really started off. In translations, at least we've had some kind of structure. If you look at another example of a non-packaging outweigh of contributing to Debian, then we have, in many areas of Debian, we would like some kind of design or artwork. But really at the moment, there's no kind of social infrastructure for that whatsoever. If you're a member of Debian already, or if you are known to people who are, if you're already part of the community, then maybe you can produce something, people will pick it up and use it for the website or use it for Debian t-shirts, whatever it is. But if you come along, again, as an outside person, we've had quite a few people over the years who come along and they say, for example, I've sat in my bedroom for the last six months and here's a redesign of the Debian website. Now, they've probably put a lot of work into that and they have something that we could actually be using, but when they come where there's no social infrastructure and they just come and try and dump something like that and say, well, can you use it? Unfortunately, the answer is normally, people doesn't work technically and people just don't like it, they would have preferred something else and so on. So again, this is an example of an area which is not packaging where really there is no way at the moment to easily draw people in and even though we would actually like people to work on this a lot more. So again, the unsolicited work in this kind of area is often just really gets thrown away. At least if you do a package, even if it's for some software that no one uses, your package will go into the archive and be there until it gets orphaned sometime later. If you do some artwork or a redesign of some website and you shove it onto a list, then often it's just chucked away without anything at all. So again, I mean, there's many other areas at the moment in Debian where we would like much more help, but we just have at the moment no way really to get people in. We occasionally are lucky because we find them through people who are doing packaging, for example. They happen to make some contact with someone locally in a place or whatever, but it seems to me that we could be doing a lot more to try to actively encourage people in these kind of areas or have some, I mean, again, as it has been discussed in during this Debian, for example, some kind of welcoming for people who turn up. But again, even if you have some a kind of front desk approach, you still need somewhere to direct them. You can't have a couple of people who are going to know exactly what to do with all these people in every different area like this. And again, these are really the areas where we actually need the most help in a way. In packaging, of course we want new people, but we kind of do that pretty well at the moment, whereas artwork, we're okay, maybe. Translations, we're good in some parts, less good in some others. Something like fundraising, we are desperately short of people to work on and the same for press. And in both of these areas, most of the people who are currently working are people who came for some other reason to Debian first, whereas actually there's a huge number of people out there who have real expertise in these areas and we could be learning from if we could somehow make contact and draw them into Debian. So if you are a new person and imagine that you are out there and you find out about Debian and you want to start working, we do have some documentation online, but as it is kind of normal for Debian, we have various slightly contradictory things. Actually, yeah, I mean, we've got stuff on the Wiki too, but even on the main website, we have a few things like this that you might bump into. I'm trying to drag a window across. So you might find this page. If you look for, you go online and you start searching for how do I work in Debian, then you might bump into this one. It's kind of quite nice page. It's got some useful information, but this is on the slash intro slash help on Debian.org, which sounds a kind of sensible place for someone to start. But if you see it starts off, yeah, you can do some, you can report bugs, you could help with support, internationalization, BTS, Wiki, you could start a new Debian port yourself. I mean, maybe that will happen. Different architectures, do security bugs you can donate. But again, there's nothing here about what might be described as the kind of non-technical contributions. And also, it's just a kind of big block of text with a few links out, but no, again, there's a lack of the kind of social aspect of what do you actually do with this? If you're someone who likes to sit in your bedroom and hack, maybe that's fine. You can go and read 20 different documents and come out with some great idea. But a lot of people, when they turn up, they're expecting to speak to someone and say, well, what should I do? Or is it really a good idea for me to work on this thing? Let's do another one of these. So this is on slash develop slash join. So yeah, how to join Debian? It sounds a good idea too. So what do we have here? We say you should read the DFSG, okay? Read lots of mailing lists. Yep, you can read, you can look for orphan packages. That's the kind of big contribution, that's under the contributing heading here. Basically look for orphan packages or pick up something that's half dead already. And then yeah, we've got a kind of couple of bits that have been tacked on as a kind of afterthought paragraph that actually you could also do documentation or website or translation. And then it's pointed out that actually you don't need to join Debian anyway, which is kind of true, but maybe if you were looking to join Debian then it could be a bit off-putting to say actually you don't need to bother. And again, yeah, so this then describes exactly you can become a DM, which is allowed to upload packages, you can become a DD, and yeah, this should take so many months and so on. So I mean, it's all accurate and useful information, but it's not necessarily very welcoming for someone who just turns up. And a third one from Debian. So again, you might, if you follow the links from the other pages or you might find this directly from Google, then you come here, which again tells you the first big point on the page about becoming a new member is to say you don't need to be a new member to do anything, go away. But we're open, it's okay. Then you can sponsor, do bugs, do packaging teams. But in this case, there's not even much mention of the kind of non-technical things. Is there a question or a point? I think you're being a bit harsh on the wording. I don't think they're trying to send people away. I think they're trying to reassure people that they can start working straight away. Like, you don't have to be a DD already. So we're not a closed group who's only open to Debian developers. You can get in without being closed. Yeah, I mean, I agree. I'm being a bit sarcastic that maybe that's the original intention. Yeah, I just think you're trying to put a negative meaning on it, which the wording isn't trying to convey. I'll micro agree with Ian, even though I wasn't originally gonna talk about that. But yes, I think this wording does a good job of being inviting. Although, if we really believe that, then we should go test it with some random technical people. And that leads me to my major thought here, which is, to the extent that we think this documentation works for people, then we should be able to find, any of us should be able to find five fairly technical friends to show up to this page and then quiz them afterwards and say, here are the things that we think you should have learned from this page. Did you learn those things? And actually, you do the alphabet way. You hear the questions and you find out their answers and you run it against the known good answers. And so user testing this stuff is my major suggestion here so far. The other suggestion I have is that we don't know, I can think of some semi-radical things we could do to improve our, how we describe these things and where we put them. My major suggestion for that would be to put on the front page as you scroll down. Here's the way to contribute of the month. But if we do that, we won't know if it's working unless we set up to measuring infrastructure. So we should do that. Hello, okay. So for developing there is really good documentation but did you click on the writing documentation link for the, on the developers' corner? There's nothing what suggests that how to join the documentation theme. So, and I suspect that's a little bit for the non-technical areas as well that the, how to join in the sub areas is not very well documented and you can see it. If I just browse the page and I saw nothing about, hmm, where should I start? Man page one, page new maintenance guide, but nothing, so here we can start. Look for that. We need to have to make that some translation. So maybe at this point we could just compare quickly what some other distributions apparently that do exist are the Linux distributions or other free software distributions whatever we want to call. So let's look at what do Fedora do here? Is this Fedora? I meant to make the font a bit larger. So yeah, if you go to the join Fedora page, then I don't know. I mean, I think even before going into all what the information is, maybe you can, for me this feels a bit more of a kind of a friendly welcoming page. So yeah, you have chat, join the lists, read planet, get free stuff, and then if you carry on down, we've got maybe you're one of these kind of people. You could be a content writer, a designer, a people person, an OS developer, translator, or a web developer as examples. So you see here the kind of packaging thing is not shoved up as the kind of main thing with others and afterthought, but it's a lot of different types of people who can contribute in different ways. And this, I don't know, again, just some, obviously it's different for different people, but to me the page here seems maybe to have more of a feeling that they really want people to come and work in these kind of ways. Just another couple of examples. So let's Linux Mint, apparently, it's some kind of newfangled Linux thing. So they have a get involved page here. This is a kind of bit different because they start off with, you can do sponsoring and things like this, but then you come down, join the community. And in fact, so they have joined the community without even saying you need to make a technical contribution. You can make a forum account and start chatting to people and that is already, you are joining the community by doing that. You can help others, debug and so on. Then they've got new ideas, translation, artwork, code. So again, there's a, maybe I think I prefer the Fedora one, but again, it's a set of different ways you can contribute with examples that might apply to a broad range of people. And as a final example here, I have again some distribution I heard of some time. So yeah, again, happy smiling people picture, although there are some women in there, not so many, and not necessarily a broad racial distribution, whatever, but anyway, and they have, yeah. So this says whether you're experienced or getting started, you can join the community, you can do it locally, you can chat online, you can help people, then some happy quotations from Yo-No, Yo-No, and then again, different ways to contribute, developers, documentation, design, translation, quality. I mean, in this case actually, they've kind of kept the Debian terminology a bit that developers are the technical people and the rest are something else, but still, at least they've kind of got a broad range of things there. And then again, also giving just links back to things like their Planet blog website and so on. So one possibility of one way to help people may be just basically to try and make the website information a bit more consistent and a bit more friendly to people. I think this would be a great thing if some people who have time were happy to work on, of course that's, I think I'm not trying to say that people wouldn't like it to be friendly or better at the moment, whatever, it's just again, obviously a lack of time so it's maybe some people in this room would have some interest in working on that. I just, I'm trying to leave some time for discussion, but I've got a few other slides to come through, so another thing that seems to me would be helpful from this kind, if we have this kind of website, which again, people have agreed for years as a good idea and people have done different versions in the Wiki or elsewhere, different initiatives at different times, there's some kind of more central list of, even within each of these areas, tasks that you can easily get started on. But again, maybe ideally with the kind of people that you should contact for them, not just to say this is some bit of code that's needed, but this work on this area is needed, talk to this person or this list or so on. And in fact, this could also help existing Debian contributors who are looking for something new to work on. Again, there's been a lot of discussion in this DEBCON as in the previous period, recently about different ways that we can do kind of mentoring within the project, different ways we can have temporary internships of people, whether that's in Debian overall or people who are already in Debian, even within specific teams. A few teams have already done this to try that you can try joining the team for a few months and see how you get on. And again, this is also something that's useful for existing contributors. Again, another thing that people generally agree is a good idea, I don't think this is controversial, is to say that to have more contribution, more communication from teams of what they're up to. Again, this helps within the project, it helps people who are actively trying to get into the project. I mean, I was actually, again, I was pointed out to me, this also helps people who just want to lurk, to start with. The more you have kind of good information clearly there, whether it's on lists or even on planet, even on IRC, but as long as it's on some channel that people can kind of find. A lot of the people who do want, certainly a lot of people who want to work in the technical areas, maybe they want to just lurk on a channel for a few months first and see what happens. But they can only, people who are not yet in the community can only do that if they can find out how to do it. Not if everything happens on some IRC channel that's hidden from the channel list and not advertised anywhere, so on. It seems a lot of people who get, a lot, if you ask people how they got into Debian, for most people there was some pre-existing personal link. Although I think it's very important that we could have some better information on a website and so on, that's not normally sufficient to really draw people into a community. Most people, they have someone they knew in their town or someone they knew from university, whatever it was, who originally introduced them to Debian. So one thing that's being brought up and actually Zach was quite interested in the idea, although not much has really happened on it in the last couple of years, but again due to lack of time from people, is the idea of pushing some more kind of activity of local Debian organizations. What we have successfully done is to create bureaucratic Debian organizations in many countries which can hold money and things like this. There's been, it's much more variable between different areas whether they actually have any kind of social meeting or any events or things like this. And often what happens in practice is that you have a few Debian developers in the city and they may occasionally meet for drinks themselves but they don't really advertise that as a Debian event, they just meeting with their friends, which obviously is fair enough, but it does seem that there is some space for us to more actively push some of these things as local groups or whatever. Obviously again in many places, in most of the relevant places there are already different technical meetings including things like Linux user groups. But certainly nowadays, maybe 10 years ago there was much more overlap in my personal experience, there was more overlap then between the kind of Debian developer style or interest and things like Linux user groups. Now a lot of them have moved much more to actually be Linux user groups as the name suggests and have things like talks about how to use open office or this kind of stuff that isn't typically so interesting to people who are pushing to actually make some free software contribution, it's a slightly different angle. So again I'm not trying to say that we should fork off or split away from any groups we are part of already, but in many places, certainly in bigger cities around the world it may make sense to have some kind of advertised Debian meeting even if in practice it's just a couple of DDs who meet for a drink. There's not really any harm to advertise that and see if anyone else comes along who wants to get involved.  So things like local groups, again if anyone wants this, if anyone has specific ideas about the website or would like to volunteer to help work on that, anyone who wants to, who thinks, or I mean again there are some kind of task list already but it really needs some people to more actively curate them to try to seek out things that are easy topics to people to join or find points of contact and so on. Again other ways, if anyone has ideas of other ways that we can find people for what are normally kind of described as the non-technical tasks, as all the tasks that aren't packaging in general actually and other ideas that people have. So who wants to start? I can say something. I think that the ideas were great about how to simplify documentation. I think we should do that but it does not solve the core problem you mentioned in the beginning that many people might want to have social interactions in someone and I'm not sure if it's possible to do that online, maybe we can try to do that but I really like the local groups idea but the problem with local groups is kind of you need quite a high density so that it works because people don't want to travel many hours for these meetings but it's something I'm considering to experiment with in Switzerland. I think it could work like rotating between cities every second month or something and then maybe we'll see how it goes. Hi, actually as one or one and a half things I think you missed what we could start with and what I was doing myself is I just started with some QA things which are obvious to do, which are described as websites and we just need somebody to have time. I mean they are low hanging fruits, they are high hanging fruits, they are very high hanging fruits so one could go up step by step. In the past I have seen once a non-developer who contributed quite many patches to the bug reports. In fact, there were so high quality, that I recommended him to start a process without a package and he went through. So yes, you could do this technical work without packages through the embosses and that's something I think we should recommend to more people and yes, it also helps them very much because we don't get yet another thing which needs to be cared of, but some of the tasks take care of the things that we actually really need help like now. Okay, there's one question from IRC about if there's a possibility or even a policy about providing infrastructure like mailing lists to local groups. Listmasters or Alioth admins want to comment. I could of course, I could comment even if not being a listmaster, but yes, so our case versus is being done so I assume it will be done for other groups as well. In Brazil, what we did was we created an Alioth project for Debian Brazil and then we create local lists inside that project on Alioth so we really trust listmasters who create those lists. So along these lines I'm very involved in Python user groups and every year at the yearly Python conference in the US there's a birds of a feather session with people who run local user groups and more than once I've seen the following conversation. Somebody says, oh yeah, I was trying to get a Python user group started in my random town in Ohio and I made a mailing list and I tried to advertise that nobody came but what I found most remarkable was that once the person sitting next to that person said, actually, I live in the same town and started to mail a Python user group right at the same time but I started mine on meetup.com and then we were flooded with attendees and we've had a great time and we eventually merged with the one sitting next to me and this is not to be an overwhelming endorsement of meetup in particular but just to say that the tasks of not just creating the group but getting the word out about the group are separate and both of them are hard and getting the word out is the harder part. No I think again, I mean it's if you have a couple of Debian people in the same city already, the easiest way is just to make them then meet socially as it is but advertise it then there's no, they don't need to feel bad if they don't have 100 people turn up at the meeting. I mean as even if it's purely a social thing that still gives a much easier social access for new people to come along and have a chat. Anyone here at DebKonf, have you met someone at DebKonf who lives in the same country as you who you did not know they lived in the same country as you until you met them at DebKonf? A few hands, I mean I met someone at the dinner, yeah, I met someone at the dinner who met someone across the table who both lived in Paris, they just didn't know. Which is to say that getting the word out is still really hard? Yeah, I organized the box question party in Shanghai and there was a lot of people who showed up who had never made anything in Debian and it was great but I was not expecting that and I think it would have been even better if I could have found some tasks for them which was up to their level and I think that maybe some others could have the same experience, that's why I wanted to share. Yeah, I've also seen this where bug squatting parties have basically turned into kind of mentoring or introductory events because the people who turned up were people who wanted to get involved in Debian rather than people who were already ready to start squashing RC bugs. Which is fine but again maybe it's we shouldn't just focus on this kind of bug squashing even though that's more directly, more immediately useful for Debian in the short term that really if you get people involved in this way that will in a long term have a bigger benefit. Yeah, so you mentioned quite a lot of very interesting ideas about improving all those ways to get into Debian. If you had to choose, well you also mentioned that lots of people lack time. If you had to choose just the three main ideas that you think you should do right now as soon as possible. It's tricky because some of the ideas I think would be most useful also require more time. So I think having, if you had a kind of welcoming people plus a curated task list and points of contact then those two already would make a huge difference but finding this list of tasks that are accessible for people coming in at different levels is a huge amount of work itself. And obviously in many cases you might even have tasks where it's quicker for someone just to fix it themselves than to really document it. But having those kind of tasks available documented is a useful thing. And again I think the local groups would make a, if we imagine we could flick a switch and have local Debian groups in every major city it would be a huge difference but again you can't just make that happen overnight. Shish again. Okay, cool. Yeah, so it seems like we got a bunch of critical mass for a Debian welcoming team yesterday and the core notion behind that is taking people who have already shown up to the project somehow, made a wiki edit or probably initially just gotten all the way through to uploading a sponsored package and welcoming them. I think we are going to end up over the next six months with some kind of bug curation because we'll want that when communicating with people. So if anyone else is interested in joining this welcoming team to greet New People then please find me, I'm a Shish afterwards. The microphone's not working over there I think. No, no, not video. Again I really want to stress out the point of that. The other ways of getting into Debian like contributing to doc or art are very well documented because someone said to me today, okay, file a bug against the new maintainers guide. Even I who is used to packages, I just thought, okay, where should I go? Then there's nothing on the web page until I thought, wait, there's a package and that's for non-technical people even much more counter-intuitive and this is the part. The basic steps are already done but we have to refine them. Yeah, well many Debian teams are not even well documented for people within the teams at the moment. There are already quite a few teams where people within them have trouble to know what's happening. When I started with IT, documentation was a way to get into because I read the documentation, tried to understand it, tried to use it and there I could go into it and this is for some semi-technical people easier and yeah. And who in the room would be interested in principle in participating in a Debian local group in their city or their region? Yeah, so I think it's possible to make these things happen. Do we have a, we're almost coming at a time. Do anyone else have another point or two? There's any, again, any of the people at the back hiding at the back of the room have a willing to voice their opinion? No, all sleeping. Just wanted to mention my very small experience. Last year I organized a best question part in Dublin just because it was the freeze and I saw there was no other Debian events and then I realized there was no Debian community and a lot of people show up and well I had to leave the country anyway so I couldn't continue much with that but there is kind of a local Debian group now that hopefully will grow with time but it was amazing to see that there was interest just somebody needed to do the first step and gather the people. It was the same in Barcelona that we have, well we have a, we use the Debian user Catalan for doing social things. Well it's a user and we can, a lot of people is asking for technical reasons but it's only used to prepare like we did a party, we did a workshop and people is looking for doing more things. So it's what Tincho has said. One person has to do something and then. I think we're pretty much out of time but Ashish wants to say something quickly. Okay, so Ashish, some last short comment but yeah. This will be very short if you guys make it short so it seems like we have a lot of great user grouping energy but we don't have anybody organizing the effort of making sure Debian local user groups happen. So what we need is two people who are willing to be co-meta organizers of Debian local user groups to keep track of those so we don't have the same event next year at DevCon so we can say that that's gotten better. So who's interested in getting in touch with local user groups and making sure that our wiki documentation about local user groups is up to date. I'm happy to help you with it. Yeah, I'm also willing to help on this but again I travel a lot so it's hard for me to constantly have time on it. So it would be very nice if one or two people maybe who, even people who aren't yet feeling that they contribute a lot to Debian this is a great way to get started in itself. Cool, we'll start with you and we'll talk more afterwards. So thanks to Mare for this great session and I hope in the next year we will see many local user groups throughout the world and in a true Debian spirit they can grow from the bottom up and it does not need coordination from the top so don't wait for the coordinators to form your local user group, thanks. Thank you.


All right, current New Yorker has a story proposing that economic growth is not required for prosperity, what's your opinion? I mean, that's just silly, right? If you don't grow, then what is it? It's a zero sum game. So we're just redistributing what already exists. How does that lead to prosperity? And given the human needs, human desires, human wants constantly expand a constantly greater than how are you going to deal with that in a, in a no growth economy? And no growth economy means again, zero sum, everything gets distributed. And now they would like you to believe that because they don't want economic growth. And the reason they don't want economic growth is twofold. One, they understand that the only way to get economic growth is through capitalism and they reject capitalism. And two, they don't want economic growth because they believe that man is a cancer on the planet and that economic growth is destructive to planet Earth. They realize that in order to for economic growth to happen, that the the band changes as environment and therefore affects the environment around him and is going to have an impact on that environment and they worship the environment above human prosperity. So the idea of human prosperity, they can't even define human prosperity. Oh, you know, we could all meditate all day instead of working hard and, and, you know, we can all grow, go, go back to subsistence farming and farm, but that's not prosperity. And that's not happiness and that's not success. Again, what happens to the ambitious hardworking person? Well, if there's no economic growth, they have no way to go. And the only success they can achieve is that somebody else's expense because it's the pie is limited. What we need today, what I called a new intellectual would be any man or woman who is willing to think, meaning any man or woman who knows that man's life must be guided by reason, by the intellect, not by feelings, wishes, wins or mystic revelations, any man or woman who values his life and who does not want to give in to today's cult of despair, cynicism and impotence and does not intend to give up the world to the dark ages and to the role of the collectivist growth. Using the super chat and I noticed yesterday when I appealed for support for the show, many of you step forward and actually supported the show for the first time. So I'll do it again. Maybe we'll get some more today. If you like what you're hearing, if you appreciate what I'm doing, then I appreciate your support. Those of you who don't yet support the show, please take this opportunity. Go to Iranbrookshow.com slash support or go to subscribe star.com Iranbrookshow and make a kind of a monthly contribution to keep this to keep this going. I'm not sure when the next.


Welcome to bloaty. It is a bluey horror game as we can see here.  All right. Oh, we found a Bitcoin mama. We rich. All right, cool All right. Oh my god. It is kind of dark and scary. Oh, what is this cool a little playground? Oh Can you hide in there?   Oh That probably made a lot of noise unnecessary noise. Oh my god. What the? Bro, what is that thing? That is so terrified. Oh my god My god, where do we go? Where do I hide? Can I escape the house that door is locked? Okay, I think we're safe.  As we can see bluey has mutated into this fairly Terrifying-looking creature dude. What the heck was that? Okay, that made noise for sure blue's gonna come this way Without a doubt. Oh, yep there. Oh my god. There she is Dude, why did she look like that bro?  That looks pretty terrifying. Hey, bro I don't know what's up with bluey after they let her go She'd be looking like a crack-hand or something. Okay, let's close that door. Oh, what is that like a walkie-talkie? No No, oh my god.  Oh That was so close. Oh my god, bro. What do we do?   Did this chase me? You can hide in the box. Oh All right, that is a little too close in person man need a back off because you got that hot breath. Oh We did something Okay, so the controls used for that I don't know exactly what that is Okay, so it made like a noise like a gate open or something not to sure where though Okay.  Oh, you don't see me.  I thought she was like really blind and didn't see me, but Apparently she does yeah, I love blue. We actually heard that or not. Oh My god, that is so terrifying bro. Like she just emerged from the darkness. That was kind of scary ain't gonna lie Okay, cool. So that key. What is that key used for? I Have no freaking idea Okay, so we literally have to search through all these This is madness Can I bluey? No bluey. No My god, okay, can we not got bluey with this? bro chill Chill bro. Oh my huh. Okay, that did not do anything. Okay open.  Oh Nice, okay, so we got that off Bro. Oh my case of the key has to be for that door, right? No dang it for this We in the cellar now. Oh Heck no. Oh for this. Oh It's a fuse. I thought it was a rolling pan, bro I thought it was a roller for like pizza or something But apparently It's a fuse Okay, so the basketballs I Think you throw these huh? Oh my god. Oh my god. No, okay, I can't I can't find the fuse anymore Okay, there it is Here, let me just go down here and place it Bro, don't tell me we need four. Are you kidding me, bro? Oh my god. I think blues right behind me Okay, you're the jail It's a dead end It's a dead end night three Here's a shortcut anything here. Nope. Oh, you can actually go outside What okay, this is pretty cool. Oh, that's locked Dude, this is pretty sick. Oh, but we can come out here too great This one I thought I was safe. Oh The basketball. Okay, where's the basketball? I threw it somewhere around here night for this is our last night Okay, this is not good. Oh What we're locked up Huh, how did we get in here? Oh, it's like a screwdriver. How the heck did we get locked up, bro? Oh, no, that's not good.   Oh My god, please leave me alone Go away. Okay.   Oh, that probably made noise. Oh, I think this is for the shed outside Louie. Oh, no, please don't I don't think she saw me. Okay. I think we're actually safe. Oh Would you look at this? What the heck is this for? Okay, let me close this real quick. I think bluey might actually come outside. Okay, if I pick this up I need to run like fast. Okay. Nice. Um, where the heck do I use this? Oh, no Oh Dude, it's like a that is an interesting build. I'm gonna tell you this right now Like that is the most interesting build I've ever seen on a monster. You're not chasing me. Are you? Oh my god Why did I stop? Come on, man Now I'm just trapped here Dude, go away Go away, don't you have another sister? Let's go to Go back to your family, right? I'm pretty sure they miss you Okay, where do we use this? It's like I couldn't move at all, bro and That is it. All right. Well, it seems like we were unsuccessful to escape bloody's house I don't know why I keep saying bloody. Bluey, man. Just say bluey I know it's for copyright instances, but it just doesn't sound right. I don't know.


Welcome everybody to Confidently Testing Word Press. If you didn't hear me ramble on this morning, my name is Steve Crenwell. I'm at Steve Crenwell on all the social networks that matter. And if you're the kind of person who likes to have your own copy of the slides to follow along, you can grab them now at stevecrenwell.com slash slide slash testing wordpress. They're also very, very, very small in the bottom of each and every slide. If you don't grab them now, though, don't worry, I will tweet them out later. Let's talk about testing fundamentals, shall we? Before we can really understand how to test well, it helps to understand the role that automated testing plays in software development. Through automated testing, we're able to codify exact testing procedures. This is going to reduce the amount of time it takes to run A, because we don't have someone manually sitting there going like, let me run through every test scenario. But B, it's reducing that chance of human error because no one can forget a step because computers never forget. Tests also become very easily reproducible because they're scripted. It's not someone's doing something in a different way or in a different order. Everybody is running the same tests. It doesn't matter if it's your CI pipeline or if it's a developer on your team. Automated testing is also very important if you want to reach that holy grail of continuous integration and continuous delivery. Obviously we don't want to be deploying to production over and over and over if we don't actually know that it's going to work, because that causes a lot of lost weekends, a lot of frustration, and a lot of drinking. There are a few different types of tests. At the base, we have what's known as the unit test. This is going to test the smallest possible unit of our code. Often this is a single function or a single class method. Moving up, we get to the integration testing. Sometimes this is also called feature testing. This takes all of these individual components that we've already tested with our unit tests and tests how they all kind of come together, how they integrate. Above that, we have end to end, sometimes known as full stack testing. And this typically is going to test the full path through an application. As a user, I arrive on this page, I click this format, I put it, I provide this data, I click this button, and I expect this to happen. We're going to consider end to end testing beyond the scope of this talk. We're going to focus on these first two, unit and integration tests. Now when we take these types of tests, they're often arranged in what's known as the automation test pyramid. Along the x-axis here, we have the number of tests. So the wider the base of this pyramid, the more of those tests we should have. As we go up the y-axis, we get the cost. This isn't just cost in dollars, but cost in time, cost in effort, how difficult or how involved are these tests to write. At our base, ideally we're going to have the majority of our tests be unit tests. We want to test the individual functions, make sure that things behave the way we want them to. Moving up, we get to integration tests. A little more involved to write. You might have HTTP requests going on. You might be changing session state, anything like that. But still generally pretty easy, pretty quick to run. Up at the top of the pyramid, we have our end-to-end tests. These are going to be more expensive to run because you're often doing something with a headless browser. You need to spin up Headless Chrome and visit this page and click this and fill this out. They're going to be more involved to write. They're going to take longer to run. They're going to be really good for testing happy paths. The user must be able to sign up for our app because if they can't do that, we don't make any money. Those are important cases to have end-to-end tests. Another concept that's worth understanding is what's known as the system under test. SUT, or SUIT, I don't know, I live online. We don't really pronounce things. But that refers to the system that we're currently testing. If we're writing a unit test, we might be testing a single method. The system under test is that method. We're actually testing a class in an integration test. That class is the system under test. We want to make sure that we're isolating what we're trying to test. And for anything else, we want to use test doubles, which we'll talk more about in a moment. So we've talked about unit tests and integration tests. Well, WordPress comes along, and like WordPress does, it makes things a little more difficult sometimes. WordPress, by its nature, is a very tightly coupled system. Different parts of WordPress are going to rely very strongly on one another. You have a lot of global variables, for instance, that are holding state. So it's hard to say, I want to test this one function when this one function has like 18 side effects that you also need to account for. Really, WordPress is... it makes it difficult to test anything in true isolation. It's admittedly a teenage dapplication because, well, that's what happens when you've been around for between 13 and 18 years. That's literally a teenage dapplication. It's still definitely workable, and we can still test in WordPress, but it does require a bit of creative thinking. If you've done any software testing in, quote, unquote, pure frameworks or more modern frameworks, you might kind of be like, well, everything has its definite place. WordPress, we muddy those lines a little bit. But let me show you what we're going to be working with today. So this is our testing toolbox. At the core of everything, it all comes down to PHP unit. PHP unit, if you haven't worked with it before, is the most popular test framework slash runner within the PHP ecosystem. There are a few other alternatives, but PHP unit is kind of by and far the one that everybody goes to. It's also really extendable by other frameworks and applications, and you can write add-ons for it and everything. And it also serves as the basis for the WordPress core test suite. The structure within PHP unit, we have a few levels to be aware of. At the top, we're going to have one or more test suites. A test suite is a collection of test classes, and it's usually you might have, like, a unit and an integration test suite, or you might have a front end and an API test suite. The next level down, we get the test class. These are literally PHP classes, which are collections of test cases. Now, these will often be centered around a particular feature or a model. You might have a user test. You might have a post-test, something like that. And within our test class, they're comprised of test methods, which are literally PHP methods, functions within a class. These are going to then, in turn, contain one or more assertions, and you can think of each test method as a scenario that you're trying to test. Now, when I say assertions, basically that's where, in our tests, we ask a question, do things work the way we expect? We make an assertion against what's happening. PHP unit is going to come with a ton of default assertions, and, like I said, it's easily extended by other frameworks or applications. So let's take a look at some of the most common assertions you'll be using in your tests. First of all, we have the question of true or false. And as we go through these, you'll see that everything really boils down to true or false. So assert true is going to do a strict comparison to the Boolean true. Conversely, we have assert false, which is going to do a strict comparison to false. We can check for equality. Things like assert equals, which is going to do a loose comparison. Note the double equals as opposed to the triple. We can do assert same, which is going to do a strict between two values. Something to be aware of here, if you are comparing two instances of the same class, so two objects that are not the same object, but the same class, they will not be considered equal. So something to be aware of. You can verify contents. So you might do something like assert contains. We have a string foobarb as, and we want to see if bar is in it. Well, yes, bar is right there in the middle. And we pass it an array. It's aware how types work. So we're looking for a value of B and look right in the middle of this array, ABC. We can use regular expressions. Any regular expressions fans in the room? Okay, I'm not the only one. That's great, because I'm like, regex guy and most people are like, what are you doing? Why would you do that? And it's just the regex people laughing at that. Like, yeah, I've been there. Most every assertion is also going to have an opposite and equal assertion. Equal and opposite flows much better, but no, let's mess that up. This is typically going to be in the form of assert thing and assert not thing. So for assert equals, you have assert not equals. Assert contains, assert not contains. Assert array has key, assert array, not has key, assert count, assert not count, so on, so forth. But like I mentioned a moment ago, everything kind of boils down to that search for true or false. So we have assert true or assert equals, which is essentially, hey, assert true expected double equals actual. We can do assert not contains is basically if we're using it on an array, it's doing an assert false on an array. If we're doing regular expressions, we're doing preg match and seeing if we got a result. So everything comes down to true or false. When we chain all of our tests together, we can get a nice output like this. Here we can see 511 tests, a total of 1,085 assertions. Four tests were skipped. It took 1.13 minutes to run and occupied 42 megs of RAM. If we had anything that went wrong, I mean you can see down here, okay, but incomplete skipped or risky tests, those are those S's up there. Each dot represents a test method that passed. If we had a failure, we might get something like this where we see a big red F and it tells us exactly where things went wrong. There was one failure. It was in copy test, test get good copy. We were expecting great well balanced copy and we were given Starbucks. So clearly we have failed. I mentioned test doubles earlier. There are five types of test doubles and I have a sister talk to this one called testing like you've never tested before because you haven't. I was giving this in San Diego last year and my friend Jessica Maurerhan, some of you may know her. She's not a WordPress person. She's in the larger PHP community but she was sitting in the audience and she's like, Steve, you only have three types of test doubles up there and there are five. What are you doing? You're wrong because she and I have that kind of relationship where we can just call each other out for being wrong but she was right. I omitted content. So here today you get all five types of test doubles. Yes. First, we have the noble stub. Now a stub you're going to set the default response values. You're saying I expect to call this function or this method and this is the value I expect to get back because again system under test you don't want to have to test some other API to say, well, I expect to call it with these values and then hopefully it'll give me the response that I'm expecting back. I'm going to say, no, if I were to call this it would respond back with this value. We have the mock and a mock is going to let us say I want to make sure that for instance this method is called two times with these particular arguments. A spy flips a mock on its head and rather than saying, hey, I'm going to call the mock and expect it to respond in a particular way you basically say, hey, go watch that functionality over there because I'm going to ask you questions about it later to say, hey, did it call that method two times with those particular arguments? We get into the dummy and a dummy is going to do nothing but satisfy requirements. If you're working in more typed PHP so move to PHP 7 for everyone's sake please but if you have type hidden dependencies that you need to satisfy a dummy is really great for that and then you have fakes and a fake is going to be an implementation of a contract or a system that you're not using in production it basically just swaps it out to go no, maybe you have a logger for instance and you want to make sure that messages are written to the logs so you sub in a fake logger that then you can go back and be like tell me everything they got written to you rather than actually writing out to the file system or sending them to a log aggregation service or anything. After I gave the talk and left out dummy and fake before like I said Jessica kind of made fun of me then she wrote this blog post and made me copy edit it for her but it's called the five types of test doubles and how to create them in PHP unit it is in the notes for the stock highly recommend reading it because she does a much better job than I do of explaining the different types of test doubles and how to create them in PHP unit because that's literally the title of her article there's also a library called mockery that's very popular it does admittedly sort of blur the line between a mock and a stub so that's something to be aware of but it gives us this nice expressive interface so let's say we have a an API method called get recent orders and we want to make sure that it handles when we get an empty order list so perhaps we create a mock of our API class we are making a partial mock which just means anything I don't explicitly tell you how to handle proxy it back to the original class and we say the API should receive get all orders exactly once and it should return an empty array now if we have a method called get recent orders we're going to assume that that's going to be empty if get all orders is returning empty so we've been able to mock that we're not actually calling out we don't have to like create some fake you know hey look there are orders in a database somewhere and now there aren't so we're able to mock this out I could talk about test doubles all day but it's going to it's a rabbit hole let's be honest run just run there's also if I may do a little bit of self promotion sometimes you need to test markup and you need to be able to say hey does this button exist do I have an element with this class and you can do this by saying like assert contains and look for specific strings I do maintain a library called PHP unit markup assertions it's essentially a wrapper around DOM document so you can do things like element selectors you know I'm looking for something with a class of both button and active in the output so that's very handy it's available for free on github so check it out if you have to do things like the short code have the elements I expected to have now that was more general testing in PHP let's shift our attention and focus more on testing within the context of WordPress the core test suite is what WordPress core itself uses and it's arguably going to be one of the best ways to test our plugins and themes as well we can scaffold our test suite if you don't already have tests in your plugin easiest way is going to be through WPC Li they have this lovely WPC scaffold plugin dash tests and then you give it your plugin name you can also do theme tests and if you're generating a new theme or plugin through WPC Li you can say yeah no no include tests and it'll put that scaffolding in place for you what do we get through WPC Li scaffolding well we get PHP unit dot XML dot dist this is our PHP unit configuration file totally stock PHP unit basically defines this is where our tests live within our file system these are things that should be considered for code coverage these are environment variables we want to set anything like that we get a PHP code sniffer configuration file if you're using Travis CI it'll generate a Travis dot YAML file if you're using other popular CI providers you can specify an alternate CI provider there as well the install WPC test dot SH script will make sure that you have a test WordPress environment the WordPress core test suite does require an instance of WordPress that it can test against and wipe out the database of so don't use your production instance if you're using a tool like VVV it's already going to have a test environment built in which is really nice you can specify it via an environment variable to say hey do all of the tests over here you get bootstrap dot PHP which we're going to look at in just a second and then you get a nice example test because who doesn't want a test kind of saying hey here's how things might look for you one of the important things that we don't get though is a composer dot JSON file composer has yet to really take off in the WordPress space which is a bummer still holding out hope but if you haven't worked with composer composer is a package manager for WordPress if you are more familiar with NPM in the JavaScript world think of composer as a better NPM but for PHP stuff instead of JavaScript stuff so if you run composer init it'll give you a nice little walkthrough and eventually we're going to get a file that looks like this this is my composer dot JSON I'm specifying the plugin name, a description for it I'm specifying the type as WordPress plugin and then able to say hey it's a WordPress plugin so I want you to install it into WP content plugins which is awesome license information, author information and then down here I have this required dev this is where I'm loading in development dependencies and in this case I'm explicitly loading PHP unit some people will use a global PHP unit installation or something built into VVV or whatever development environment they're using however different versions of PHP unit will have different structures or different requirements around them and sometimes you'll get a test that will be working in one and failing in another and it's probably not an issue with PHP unit it's just Sebastian Bergman is very cool with like no there are going to be backwards compatibility breaks because modern PHP folks it's worth noting here I am pulling PHP unit 7 because WordPress as of the time of when I put these slides together and then check the ticket two nights ago WordPress core does not yet support PHP unit 8 there's an open track ticket for it but modern PHP is usually not the highest priority that bootstrap file I mentioned earlier that gets scaffolded for you the general gist of it as we go through we're going to locate the WordPress installation it's looking for the environment variable WPTestsDur again if you're using something like VVV it's already going to define this and say nope use this one over here otherwise it's going to assume that Michelle script installed it to temp slash WordPress testlib next we're going to load one file from that test directory which gives us access to the test add filter function we're going to write a hook or we're going to hook in using that test add filter function I wrote line as a closure because we're all using PHP 5.3 and above and because otherwise it wouldn't fit on the slide and I'm loading the main file from my plugin so I'm simply requiring that on any plugins loaded and then I'm going to bootstrap WordPress core this bootstraps the core test suite it starts going okay let me set up the WordPress instance make sure everything is the way it needs to be and then start running through the tests if we were just writing regular PHP unit tests our test classes would look something like this we have my app test extends PHP unit framework test case if we're working in WordPress we're just going to swap this out and instead of extending that base test case we're going to use WordPress's WP underscore unit test case and then get into our test methods PHP unit offers us a handy little feature called fixtures if we have common actions that we're repeating over and over I always need to scaffold a user before I run any test in this test class we might use a fixture so you can say I want to do something on setup this is going to run before every test every test method carry down after every test method we also have set up before class which will run once at the beginning of the test class tear down after class at the end of each test class we also have annotations we can do at before and say do something before each test method we have at before at before class at after and or at after class annotations are weird to say out loud again we don't use words vocalization difficult when we have tests especially if we have multiple test suites if we have multiple test classes perhaps there are features that are a little more tightly coupled and we want to make sure anything related to this one thing are tied together I want to be able to run all of those related tests at once that's where this at group annotation comes in see that one I can say out loud at group so say we have our test includes private posts maybe this includes both it's relevant to posts and post meta we can use this at group and then by running PHP unit group equals posts any test class or test method with posts as its group will get run so that's a really nice way it's totally flexible you can arrange it however makes the most sense for your application but we're able to keep this stuff together which is awesome if you recall earlier when I had the skip tests we do have these two helpers available to us through PHP mark test incomplete and mark test skipped they behave in a similar way but they have slightly different meanings an incomplete test is really great if say you're developing a new feature you're trying to practice TDD and you're like okay I know that it's going to have to do this, this, this and this and I want to make sure that I'm testing in this error case so maybe you stub out a bunch of functions or test methods but you haven't had time to actually write the test you might mark them as incomplete, just kind of they're here to remind me to write this test mark test skipped on the other hand this is typically going to get used if you have maybe an issue where all of your tests are running fine then one test fails and then everything after that starts erroring or failing and you're like am I polluting something here, am I testing that cleaning up properly, what's going on so I just want to temporarily remove something from the test runner that's where mark test skipped comes in really handy if you have a production code base where you have a bunch of test marks mark test skipped that could be a code smell that someone's basically like I can't get these tests to pass clearly not my code it must be the tests that are wrong so people just sort of remove it and then things fail data providers are one of my favorite features and I realize that this talk kind of went like let's talk the WordPress stuff let's go back to all the cool people and stuff but I get like abnormally excited about data providers if you have a similar scenario that you're setting up and it's just kind of same play, different actors you can use data providers to inject different data into it in this case we specify okay data provider I want to use my data provider which refers to this method down here I have the same setup and I'm taking arguments so expected and actual and then I'm doing the same assertion admittedly you'd normally see much more in here but for the sake of privacy on a slide I kept it pretty low but down here we have my data provider which is returning an array we can give each one a description so we might say like I want to do a URL parsing I've done that one probably a hundred times I should really abstract that into a composer package come to think of it but maybe you're saying I want to make sure that like I'm finding all of the matches for a YouTube URL so you might have like full YouTube URL short URL with query string whatever you can define all of these things and then these arguments are going or the the returned arrays are going to correspond to the arguments so the first time we run through it we'll have description of case one foo would be expected bar would be actual second time description of case two bar would be expected as would be actual we only need to do these data providers once and we don't want to break it out into a separate method there's also this at test with annotation which is really nice we can put it in the doc block at the top of the test method again foo bar would be expected an actual respectively one caveat here we can't do any sort of variable interpolation we can't if you're trying to use constants or call another function anything like that you're going to have to use the first method with the separate data provider because this actually is a method that returns an array but if you're just using kind of simple data oh I had the word and it was awesome I was going to blow you all away with how smart I sounded and now I've lost it damn but yeah the simple data that I can't remember the scaler, scaler types, boom anyway alright the rest of these I put a nice W up there to show you that these are WordPress specific uh so here's what we came here for right factories are included in the WordPress core test suite and these let us easily generate test data so maybe we need to generate posts or we need to generate users or comments or terms or attachments we can do all of that with the core test suite which is awesome we could say okay this factory post create and we could pass it an array of arguments to change what the post will look like but this is back a post ID of a post that it just created it's not going to be like award-winning post content I think it says like this is the test content but I don't have to create that post I'm not calling WP insert post and pretending that I uh have that kind of time if we need to get back the object that was created we can use this create and get so we're doing this factory post create and get which gives us the post object if we want to change just a few things if we say the post title I really want to make sure that it's my test post because maybe it was like example post before or I need to assign a particular author ID to it I can pass the post offer there those just get passed straight through to WP insert post we can also do create many if you need to for instance say okay I have an author that I've created and I need to create five posts and assign them to them you can do that by creating the author and then you take the author ID and you set that as the post and you just create many with five so a lot of cool stuff that you can do with factories a common use case within testing WordPress is going to be impersonating users if you need to make sure that for instance someone who has an author role can't blow stuff up usually that's reserved for admins right we don't want our authors blowing stuff up maybe editors sometimes but usually only administrators or super admins get to blow stuff up so we're going to create a new author level user we're going to use this WP set current user to their user ID and then we're going to do like a capability check can the current user blow stuff up we want to assert that that's false and because we're acting as them by doing this WP set current user this will return false and hooray only the admins can blow stuff up the core test suite gives us the go to helper and it's going to change the current page context as if you visited a new page keep in mind it's not actually going to make that HTTP each I added an extra T HTTP request but it's going to reset things like the super globals the globals the query variables the main query as if that page has been requested so again not an actual request which is good on saving time but something to be aware of so in this case we have look I'm not on the home page and then I go or what evaluates is home which is the page for posts which is confusing because legacy so if we go to slash blog now we're expecting is home to be true because we had set that as the page for posts in this particular site a custom assertion included with the core test suite is assert WP error which again because everything comes down to this the search for truth is essentially a assert true instance of WP error but it can be really nice if you have something that for instance might return a WP error and maybe you want to make sure that what you get back is in fact a WP error object so let's start talking about writing our first test I've given you the tools the knowledge I'm sure you could all go out right now and start writing tests and be like I'm confidently testing WordPress but for those who would like a little walk through I guess we okay let's do this so as we go through these tests I want you to pay attention to this pattern arrange act assert arrange we're going to set up the scenario we're going to generate any posts that we need we're going to set any filters that we need whatever act we're going to actually execute the code the system under test then we're going to make assertions we're going to verify that things happened in the test the way we expected them to so let's go back to the idea of testing permissions because again really this ends up coming up a lot at least in the work that I've done throughout my career imagine we have a function that clears the site cache but the function itself is checking user capabilities before someone does something if the user doesn't have permission we should get back a WPR object so up here we're going to start by changing the test like we did in the previous one we're going to create an author so we're using the user factory we're going to impersonate them and then we're going to try calling my plug-in clear cache we're going to save the response to that it to a response variable then we're going to do a certain WPR response because we expected an author would get a WPR back and maybe we want to do something like make sure that the error code that we get back with the object is a 403 does that kind of make sense to everybody we're setting up the scenario we're acting on it and then we're making assertions maybe we have a custom post type I mean I'm guessing at least one or two people in the room have registered a custom post type yeah okay I was underselling it has anyone not done a custom post type before they're awesome set all right so we register a custom post type in this example we'll say that it's book maybe that gets registered by a function in our plug-in called register post types because naming things is hard so then we're going to get the post type object of book stored in post type here then we're going to start making assertions about that now we don't have to check everything we don't want our code to necessarily have to redefine like you don't want to write your code twice once in your time once over here but we want to make sure that the key points stick we want to make sure that the post type actually got registered get post type object we'll return no if it doesn't exist so this makes sure that books are actually a thing big fan this maybe we want to make sure that the post type is public because if you happen to set it to private suddenly your plug-in will break in all sorts of mysterious ways so we're going to make these select assertions we're not worrying about things like make sure that the actual is exactly this or anything like that and maybe we want to make sure that it's hierarchical or it's not hierarchical so we put an assertion in there we can test hooks as well if we want to make sure that a custom action was called we can use the function did action which will return the number of times a particular action was called in this case we're there's nothing we have to arrange we can act and call and function and then we're going to make sure that we're seeing exactly one time that my act or my plug-in underscore action was called as we called my plug-in function if we want to get a little more introspective and this is also where the test double start kind of coming in we could actually hook into that action I've used this pattern plenty of times where you set up a variable something like called or did stuff or whatever whatever that sparks your mood that day then we're actually going to register a callback on the my plug-in action we're going to pass it a closure here and using the use keyword we're going to make sure that we're passing in this called variable by reference so if we make a change in here to say hey called is true then that's actually going to change it out here in this scope down here we can call the function and then make sure that we're asserting true in here we can take in any arguments we need to right here so arguments that would have been sent to the function and we can do additional assertions this makes sure that it's not just saying hey you passed because I never actually did the assertions in there and in here we can do did it receive exactly these arguments did it behave in this way did stuff blow up unnecessarily were errors triggered anything like that WordPress has a tendency to print a lot of things to screen things like the title come to mind where you're not returning a value you're simply echoing that to the screen so a lot of template tags short codes things like that are often going to echo things well not short codes don't do that with short codes but things will often be echoed directly to the screen so it's important that we're able to test output I prefer this pattern where you do the OB start this is PHP's output buffer if you haven't worked with it before basically it says hey don't print anything just kind of keep it in memory then I'm going to call do short code pass the short code tag that otherwise would be in my content and then OB get clean basically says reset the output buffer but also return anything that was printed since I started the output buffer so basically I'm able to get the output of do short code right here in the output variable and then I can do assert contains if I needed to get deeper into it make sure that certain selectors existed or anything that's where that PHP market assertions library I mentioned earlier comes into play if you know exactly what content you're looking for you can do kind of the short version and just say hey expect the output to be exactly H2 latest posts closing H2 and then just call do short code this doesn't let you do kind of partial matches or like hey let me throw some variables in here and kind of whatever but if you know the exact string you're looking for this is a nice clean way to do that and one of the most common use cases you'll run into is stubbing HTTP requests again we should not be testing the API is that our our themes or our plugins rely on that's not the job of our tests we have our system under test and if the API over there changes like that's kind of on the API the pre HTTP request filter is the way that we're going to short circuit WordPress HTTP API a lot of words there short circuit the WordPress HTTP API so that would be WP remote get WP remote post all of that normally this filter is going to do nothing but if we return something it goes oh I already have a response I'm just going to not execute the stuff where it actually makes calls so in this case we have to return something in this form because this is how the HTTP API responses look so we have like headers and body in this case we're saying okay we have an empty body but a 200 okay status code if we needed to test like well how will this respond if I happen to get back a 404 from the API or a 401 or anything like that we can start changing these values we never actually call out to the API but we can predict the responses that would be coming back because we're literally the ones providing them so let's take all of this and put it together there's a concept if you haven't heard the term TDD before or you haven't practiced TDD before test driven development it's it can seem like a foreign concept general idea of TDD is we're going to write tests before we write any actual implementation to describe the functionality or behavior of our code so we say okay I'm going to be writing this function and it's going to need to be able to accept these kinds of arguments and when it gets these particular arguments I'm expecting to see these responses we're writing the tests before we write the implementation now these tests are going to be failing because of course we haven't written anything to make them pass we're just saying oh this function will do this it's doing like the sales pitch and now the developers have to come in and be like oh no we actually have to implement this thing now we're going to write the code the minimum amount of code necessary to make those tests pass we've described how it should work now we have to actually satisfy that contract we have to say okay what code can I write to make this work test surpassing then we can go back we can start saying well this could be done in a more performant way we want to use functional programming here because it's so hot right now that's where you can go back you can refactor you can try to make things better before the first time you write the code you're writing just the bare minimum to like have we satisfied the requirements or if you're some people I know you never go beyond the bare minimum but I'm not making fun of Seth or anything sorry Seth I had to pick on someone yeah so this is often referred to as red green refactor red because we're in a failing state when we've written the test but we have not yet implemented the code green because the tests are passing yay green is awesome and then there isn't a good color for refactor so it's just to stay in plain old text where TDD becomes really handy is in what we call regression testing so this is a way of making sure that you have a bug you want to fix it once and never have that bug come back again now imagine we have this function called recent posts heading and it's going to take an array of posts and if it's empty it'll say there have been no posts in the last 30 days otherwise it'll say there have been X posts in the last 30 days some people might see where this bug exists already so if we run this with zero posts we're going to see there have been no posts in the last 30 days cool if we run it with one one posts in the last 30 days I'm not cool with that that hurts and then two posts in the last 30 days okay we have a bug in our software it's making us look like we don't understand how pluralization works let's write a test for it let's say we maybe hadn't had any tests before because we're just getting into writing tests so we do something like this we have a data provider and we're saying okay when I have zero one or two I'm expecting there have been no posts in the last 30 days one post one spelled out because one as a numeral at the beginning of a sentence is awkward one post in the last 30 days or two posts or X posts whatever so we could keep going on saying like at 15 we want it to you get the idea so in our test we are using a factory we're creating many however many we tell it here we are setting the expected output to expected which again is going to be the string there and then we're going to call recent post heading on the post array that we generated now we haven't fixed the bug yet so our tests are going to be failing we still have a situation where we're looking for one post in the last 30 days but we're still getting the number one posts in the last 30 days I die a little bit inside every time I have to say that so we look at our code and we go okay we've been able to reproduce the bug we have something telling us hey there's an issue here you've reproduced it and we add in an additional conditional statement so we say okay if we have exactly one print one post in the last 30 days for everything above one so we've covered one everything else do X post in the last 30 days now our tests are green they're passing we get to go to Chipotle or Happy Hour or whatever what's important here is that if someone comes back and maybe we have a merge conflict or someone's like I really hate el-sif because there are people who are like they refuse to use el-sif and I don't understand it it doesn't make sense to me at all but if you want to sacrifice a third of logic cool maybe they remove that well suddenly we're going to go back to a failing test because we have this test in there saying hey it needs to cover this scenario so we will hopefully never have to solve this bug again which is awesome because I hate repeating myself despite the fact that I do it over and over and over so with that we have like two minutes I don't know if it's a 45 or 50 minute slot timing do we have time for questions alright either way let's do the clappy thing now are we all confident testers do we have time for questions yes okay so if I'm understanding correctly basically how do we make sure that after we say we're not actually going to call out to the API we're going to stub everything and then what if that API changes or they introduce something new and things break in all sorts of miraculous ways I've done that more times than I care I've actually started writing like side tests that just kind of get run not as part of the main test suite but rather as part of like hey this is what I'm expecting to get once a month on like a cron through a CI server like call out and make sure that like the responses still sort of match part of that speaks to API versioning as well some people will just break things I've already been pretty critical of Facebook today so I'll give them a break here no I won't they do that a lot and it gets really painful but yeah you get into kind of this sub thing so what you want to make sure that you're doing is if you can't know that things are going to change but you want to make sure that you can adapt quickly I often will write helper methods that'll kind of be wrappers around that API so I'll have like a mock this request and I'll pass in the relevant data that I need for my individual test case but I will have like a single method that kind of this is what I'm expecting to get back and I can fill in whatever details I need to but if something breaks I can go oh this is okay this is how it broke and this is where I can change it in my test so moving forward things are cool changing APIs that's kind of one of those like we're going to build everything built on everything else as long as nothing changes we're cool unfortunately that's rarely the case so is it one more that I have time for or was that the one that was the one okay if anyone has further questions I'm around the rest of the day I will be at the the after party as well and thank you all so much


The Brainerd Little Falls girls hockey team is off to a hot start. The Flying Warriors are undefeated in four games this year, averaging just under nine goals per game. Tonight, they hosted Sartel Soc Rapids looking to stay unbeaten. And the Flying Warriors took the lead on this one first in quiet first period. Brainerd gets on the top one, nothing here in the second. Then defense was key tonight as Nicole Schultz was an absolute wall blocking this shot here, but then it was the Sabres. Grace McCabe, she races down to make the power play goal and tie up the score. But the Flying Warriors, they wouldn't go away with a little more than two minutes into overtime. Olivia Wiscoe just pushes this one in, assisted by Sophie Robinson. There's your game winning goal as Brainerd wins in OT two to one. If you've enjoyed this segment of Lakeland News, please consider making a tax deductible contribution to Lakeland Public Television.


And Niger Delta leaders and prominent groups from the region have expressed mixed reactions following the passage of the petroleum industry bill by the National Assembly. While some commend the 9th National Assembly for passing the bill after 20 years in limbo after stakeholders rejected, the 3% of oil companies' profits are located to host communities by the lawmakers. A retired Deputy Inspector General of Police and Stullworth of all Progressive Congress Udom Udo Ekwodom argued that the National Assembly members from the region did not do enough to ensure a better package for host communities in the bill. He insisted that the 3% allotted to host communities be reviewed upwards for the sake of peace and justice. Also the President of the National Congress, Professor Benjamin Okaba, the President General of Urobo Progress Union, Olorogun Moses Tega, and former Deputy Speaker of the Cross River State House of Assembly, Orok Oto Duke, all expressed displeasure over the 3% profit allocation to the oil-producing region. Notified about fresh news updates.