Hello, everybody. Can you hear me okay? Yeah, apparently there's a bit of intermittent problem with With the beamer, but there's nothing I can do about that. So sometimes the picture goes away, but it tends to pop back up so I'm going to talk a little bit about testing small projects and medium-sized projects with B-hat My name is Peter Franzen I'm from Belgium, but I'm now located in Bulgaria on Drupal.org. I'm known with my short name B. Franzen You can find me on Drupal.org and also I use the same name on Twitter And if you want I just posted the slides on my Twitter account So if you want to refer to them later on you will be finding them there. I work for Aussie It's an outsourcing company in Belgium. They have a stand here If you're maybe looking for work in Belgium or Brussels or for nice projects Then pay them a visit All right, so testing I'm going to talk a little bit in the beginning about testing in general and how you can apply it in your daily work So I have this little infographic that I found on the internet and It nicely highlights like four different ways that teams Tend to use testing in their daily work So the first type of testing you can do is to automatically run a full test suite on all supported platforms after every push and get Another way to do it is that you have a QA engineer who tests the new features and then also clicks through the website to see if There are any regressions and if the yeah if the existing functionality is still okay Or you can have like developers testing the new features on their own machines And then when everything's fine you deploy to production or finally which is like called the holy grail of testing It's like you don't do any testing and just rely on the client to report bugs So maybe can are there any people here that like have an automatic test suite running on their systems? All right, very very nice Do you have other people that have like QA engineer in their company that this like Responsible for the testing great and then who does testing on their own before they deploy to production All right, and is there anybody who doesn't do any testing? Yeah, okay, very brave. You have a very good client relationship. I guess good all right, so Why would we want to do testing there are a few goals? first of all we want to prove To our clients that the requirements they have for the projects are being met. So the client asks for certain functionality We implement them and by testing the functionality. We can actually prove like okay. This is actually working also You want to prove that all the input to your code is being handled correctly like the big Example is like a sequel injection if you have certain Bad data being input to your application You want to make be sure that nothing bad happens and also a nice goal of testing is to actually find bugs It's like unknown bugs when you start testing your own application You suddenly find some bugs that were there and you can lock them and fix them and Do the for me the biggest part is by testing you can prevent Regressions from occurring a regression is in the eyes of our clients one of the worst things That can happen. It can really sour the relationship we have. It's like yeah, we develop like a newsroom We deploy it on the server. Everything's fine three weeks later. There is a bug It's like the newsrooms not working anymore The client reports it. This is a fatal error or something we fix it But then two weeks later It's broken again and then it very often happens that the reason for this page not working anymore It's not the same reason as before there might be some other part of the code that was responsible But in the eyes of our client that looks like Hmm, they made a mistake and they made the same mistake again Do these people actually know what they're doing, you know And if you actually use testing in an automated way, you can test everything you've built before and day after day Proof that it's still it's still working than this way you can actually prevent regressions from occurring Now why would we not only test stuff manually but automated first of all, it's a lot faster Like if you have a machine clicking through your website and filling in forms, they can do it at like a rate of a few pages per second and a manual tester can never handle such a throughput also, it's more reliable like People testing so it's like even if you have a script you can forget stuff or he can be Time pressured like in these if you have a machine doing it. They will be very strict Okay, this is the stuff we need to test they will do it in the same way again and again a hundred times a thousand times They will never get tired also, it's better for your coverage because Like if you're handling input, it's easy in an automated test to check like okay We are going to test creating 100 nodes in our overview You can do it like asking a human tester to write a 100 articles I mean, it's like almost an impossible task, but having a machine do it They will take a few minutes or something and they will just crunch through it. It will be fine And also it is very reusable you write a test once and it's very cheap.  So you're actually using the product There are also unit tests that you can do a unit test Most of you will be probably familiar with it. It's a object-oriented way of testing It's like you have a piece of code a class It has a number of functions of methods in it and you will test the functionality of every little component on its own And it's typically a very fast way of running tests It's like you can try like a thousand inputs to it and it will run that in a few milliseconds You can do like stress testing low testing performance testing this will be typically on a on a live website or on a Acceptance environment you will just like try out what happens to simulate of like what happens if a thousand visitors come to our website at the same time Is it's able to handle that is our caching able to deal with this You can have regression tests really important as I said like you had a bug client reports a bug you fix the bug write a test that checks that this particular book has been fixed and You can automatically try that again and again Then there are like very specific test which they call a smoke and a sanity test This is maybe not so familiar. This is a very Quick running basic tests that you can do when you do like an automated deployment to a production environment It will like very briefly go through the most important parts of your website and check that everything's fine I could pay a visit to the home page see that there are no fatal errors there try to log in on the login page That's fine. Maybe like go through your checkout if you have a An e-shop Like really quickly takes five seconds or something if this works fine, okay? We're gonna deploy to production if anything goes wrong if the home page doesn't load Okay, we're gonna roll back and we're not going to deploy it today And then the final one I want to mention is a B test Also very specific use case. It's very often used in marketing It's like you have two versions of two variants of a thing like an advertisement or something And you serve 50% to one segment of users and then the other version to the other segment of users And then you compare how well it works. You can also use it for like usability testing Yeah, you have a new call to action button or something then you can find out, okay Do people actually have an easy way of finding this and using it? All right, and there are also some kind of tests that are not automatable at all So they can only be performed by humans and one of them is acceptance testing So like when you use agile you're developing stuff for a client the client or the product owner will want to go through the functionality Manually and actually verify before they say, okay, this meets my expectations and you can merge it into the main product second one alpha beta testing I guess everybody knows what is this you have a Pre-production version of the product Just announce it to the world. Please people test this report any problems you find I mean this you cannot have a machine do it as you really need human attention here And then the final one is like usability testing and accessibility testing Is my product easy to use is it accessible to people with disabilities? You cannot have a machine try this. That's a human task Then I want to talk to you a little bit about the business value of having tests So I want to talk about like why would you like to have tests for like a small client or a medium-sized? project because most of the time I hear from people like okay, we have the small project We only have a limited amount of time to build it. We have a limited budget But we see the value in testing it would be good to have this But how can we like convince our client that this is actually worth the time that we invest into it because of course It takes some time you gain also time because you will have fewer technical depth. You will have fewer regressions So in the long term, I mean for a big project. It's easy to justify it But for a smaller project, it's like okay, maybe we're only working on this project for three months We don't have like the really long-term benefit of having a big automated test suite But anyway, it's so it does reduce the QA effort if you have QA engineers Even if your project only runs for a few months, they will they will have an increased log of tests to do every day So having been able to automate this will just save time on QA every day as long as a project runs You minimize regressions even in a short and in a small project You will deal with regressions and you can avoid many of them. It increases the stability of the product By having some tests you are like you can have full confidence that by the time you're ready to deploy This everything is working, you know It's like in this in this time you will have run tests a thousand times and it's like yeah We've passed this it's a thousand times. It's really stable. It's really working It also improves the quality of the software Because by doing tests you will find more bugs you will have them fixed You will be aware of them and the quality of the product will increase The delivery process will also be streamlined. It's like if your client finds a Problem or they have a really urgent new feature the time to market between like getting the Request from the client and actually deploying it to production can be a lot shorter because all of this testing is automated It's like you can develop it run the test see okay. Nothing breaks. We're good Deploy to productions can go really quickly and also and this is I think one of the most important points if you are using agile Who is not using agile? Everybody's using agile if you're using agile you're actually required to use automated testing It's a key component of agile. Yeah, actually you have to Test stuff iterate over the test. That's the cycle. We do an agile. So if your client wants to use agile I mean you have to use testing All right, so agile. Let's talk a little bit about that and in our daily works We will have a ticket. How will we deal with this stuff? So we're all building websites very typically By the time we had get a feature from our clients until it gets to production There are four tasks that need to be done. First of all, we will make wire frames Or mock-ups or whatever you call them So the client has a maybe an email or they made a ticket and gyro something we will make a wire frame That will serve as a guide for the development team and the designers to know where things will be placed on the page How it will look roughly? This wire frame gets built first once it is done We can have two teams or two people Starting working in parallel. So the designer can start to design the wire frame make it look really nice And the back-end team can begin developing the functionality that's described described in the wire frame When those two are done Then the final step can take place the front-end development can happen because for the front-end to be done You need to have the design and you need to have the back-end functionality built Once this is done You're ready to deploy to production Now when we use testing, how does it come into place actually at each of these steps? You can do a quality assurance step and a user acceptance step It's everybody familiar with the beauty storms. It's like key agile terminology, so you will somebody will make the wire frames The QA will be done by somebody of the technical team to have a look at like if this actually practical to developers and to Paul Are there any like technical reasons to make maybe do it differently? Then UAT will be the client or the product owner having a look okay This wire frame matches what I want to go ahead Then the same thing will happen on the design part. So the design is being built a Technical analysis will be done like can we actually translate this into html and css Client will look again. They will have like a lot of remarks about the design the blue needs to be a little bit different and then on the back-end development Another colleague like somebody will develop the feature another person will have a look at the code like is this good? Is a code well written are they any security vulnerabilities and also? The QA engineer will look at the tests that were written for this feature and See is this test comprehensive? Does it match? Is it good? It isn't some part maybe a method or something and then when this is done Okay, we will have another uat step the client will check it Does it work correctly and then we go to the front-end development and actually the same thing will happen there Especially if you develop some JavaScript on the front-end Somebody will need to look at a code and the client will need to approve it again All right And then I guess also everybody's using get hopefully anybody not using version controller get Okay, so in get it will maybe look a bit like this So you will have a master branch which is not on the slide the master branch shows actual state of the product in production Then there is a develop branch which contains the code which is going to be deployed on production in the future and then We have a feature branch this feature branches actually Will be the number one two three four It's like in like if you use gyro or similar software you can have like a main ticket with sub tickets and You can give like the feature is all for Development steps together and then each of these Steps that need code written will have a separate branch So there will be a back-end branch which will be in this case number one two three seven And then the front-end branch will be one two three eight, right? so you branch off from the The feature branch start developing Once it's done and it has gone through QA and UAT then you know, okay the back-end Development has been done. It's good. It has been looked at its test that client has approved it at this point You merge it back into the main ticket. This means that the main ticket contains approved code If it gets rejected you stay in the back-end tickets and keep working there And then you do the same for the front-end So working it iterate over it until it's ready Contrude QA and everything then you merge it back into the feature branch Have a client have a final look and only when it's done you merge it into the develop branch So this means that the develop branch at any point in time will contain Working code which has been approved by the client. It has been looked at and they are fine with it And this is really good Because at any point in time you can receive a phone call from your client and says like we have an emergency We need to have a bug fix deployed today And you can just deploy your develop branch in full confidence because the stuff is tested and ready So you shouldn't know point ever get anything in develop which is Not ready for prime time This is does this make sense everybody? All right Good a few tips So create sub tasks if you use gyro or I mean every project management software has a similar way of grouping these tasks together Work is separate branches Do QA and UAT for everything that's important and only merge when it's done meaning when your tests are green Okay If maybe if you don't know a green test is a good test the test that passes that works, right? And then the end result is your product is always shippable It's like you could at any point in time push the button and deploy to production because your development will develop branch will be good Okay, now in agile We have this concept of the definition of done I don't know if all teams use this Very strictly But most of the time like you need to have some kind of rule to say When you are done with development and I think a good way of doing this is using this list So when is our ticket done? It's done when the implementation is complete So we actually build what the client wants when the documentation is complete We we wrote some documentation explaining how this feature can be used for the future You never know you get a new one person on the team Tests are added The tests are also passing if there is any test not passing this means you introduced a bug somewhere a regression and I mean you should never get anything through it's not done if your tests are failing the ticket is not done Then also provide manual test instructions in a ticket And I'll get back to this later, but it's really nice because your ticket will go on to a QA engineer and a UAT Engineer if they have step-by-step instructions that explains exactly like look I log in as an administrator And I go to this page and I press this button and then this will happen because very often in a ticket It's the functionality is described well, but you're not completely sure which URL do I have to go to? Oh, I actually have to see an error message on the but what are the exact words that are being used in this error message I mean if you provide these step-by-step instructions people can just follow them Retrude them and they have instant knowledge of what the functionality that has been built Also, if there is any technical depth being introduced in the ticket If you know that you put a workaround in there because you didn't have time to fix something properly There might be a bug in Drupal core in a module something happened and you can fix it later put it to do as A little comment in the code saying okay I acknowledge there is a little bit of technical depth here make a ticket in gyro or in your software and Put the ticket number at the line of code that you put there So did you keep track of your technical depth? This is something like I at the moment in time when you do when you create this workaround You're very aware of it three weeks later. You forgot about it and there is this Bug left and it will be forgotten for everybody So it's nice to have this in the definition of done so that you know like okay. I need to do this Before I can move the ticket on now when it gets to the QA The first thing you should do is actually check that the different definition of done has been met So are the tests is a functionality complete? Are these steps step-by-step instructions there? I mean come on do I really need to go through this gyro ticket and 50 comments to know what's being developed here Please give me the step-by-step instructions. It's not there. I reject it You should do a code review this review all the code have a look for security vulnerabilities Is it well written cannot be optimized? Maybe? And then also have a look at the test coverage which which was built by your colleague is is enough It's like you don't have to be incredibly strict by the way I'm not telling you if you build a website for a small project That you have to test every single feature in detail. I mean there's stuff That's really important for the client, but if there is like a certain link in the footer I mean you don't need to test the really obvious and minor stuff But you just assess it You know it's good to have a second person have a look at what has been built and just have like an idea Maybe you know You test that if we use facet filters on the on the search page that it works But you don't test what happens if you turn it off again because everything should appear you forgot this step So that's a very good thing to do all right now Another part so we're done with the agile stuff I Think that even if you have a small project you should aim to get continuous integration working For your team. I think personally continuous integration is critical for success of a product project You need to be automated The stuff like the first time you do this will take time But if you already have experience with continuous integration like the next Project to use in continuous integration will be really quickly to set up does everybody know what continuous integration is about you need to explain this okay, so What's really good is that you make a change and you push your code to a branch That the tests will start running automatically you don't have to think about it You don't have to start them manually. You don't have to depend on some person to Like install the website on a machine and run the test. No, it should be fully automatic and Also, you can deploy acceptance environments automatically Often like a client will want to test new stuff before it goes live and it's really good that this happens automatically I mean you can go like use a service like Amazon Deploy a testing instructions and an email to the client and so like yet the new feature He asked for it's ready for testing on the server. Please go to this address log in there and you will find This ticket there and please give your remarks and there are many ways of doing this I mean every organization has their own preferred way of doing continuous integration so you can use software as a service Providers like Travis CI is a famous one. There's continuous PHP. You can use your in-house Jenkins Installation, that's also very powerful. So there are ways to do this, but please if you don't use continuous integration today Talk to your bosses and say like can we get this please because it will it will make everything go really really smoothly You will get feedback of the stuff that's happening Now, okay, so we have a small project What what are we gonna test? What's important is so you test. Yeah, you test the important functionality Don't don't try to be you don't want to waste hours of time testing nonsense What's also important really test every single regression that you get if your client reports a bug If your ticket has the word bug in it Test the bug so that your client will never see the same bug twice because they will lose confidence in your abilities I also think that the test should be easy to write some tests can be really complex to write if you're writing like a unit test with dependency injection and mocking and stuff this can take a lot of time so Go for the ones that are easy to write also the test results should be pretty quick If you have to wait hours for your tests we to Give feedback to you. I mean you don't have time for this if you're building a small project You might have only three people on the team or something you don't want to wait like hours for to move on with product It should be cheap to implement on ground because Our small projects don't have a lot of budgets So we we don't want like a data center in the in the basement and people managing it I mean the the greatest thing is that you have like a service like Travis. Yeah You pay them a hundred euro per month and you can run all the tests on them. That's the ideal situation And as I said, they should run automatically no human involvement needed And then yeah, so and I'll show you the the great way of doing this is be had so we haven't talked about be had yet Little bit of history. How did we get to testing in Drupal? This will be very brief From Drupal for on there was a simple test module which was originally a counter module. It was not part of core So really early on people started to realize like look if we're building a CMS and we wanted to be stable We really need to have testing in it When they started with the Drupal 7 development cycle So this is like years before Drupal 7.0 actually got released. They said, okay We're going to move the simple test framework into core and from this moment on every single feature and Every single bug fix in Drupal core will have a test and this has been an enormous success This is the reason why Drupal today is so incredibly stable I mean, I've been using Drupal 8 since 8.0 and it has only been stable for me It's it's there are no okay. We have bugs But it's not like there are no weird things happening if it works once it will keep working and Drupal 8 They revamped the whole testing infrastructure. We are now using PHP units. We're just like the standardized PHP testing library And we have four ways of testing stuff in Drupal 8. One is the browser test base. This is functional testing We have a kernel test base, which is intended to test like integration between modules or services in Drupal 8 There's actually it's quite a smart system It will install an empty Drupal site in the memory so it doesn't use disk for this and then it will enable you to say like Okay, I'm gonna test like a node and I'm going to just Enable the database schemas of the node module and then run a really quick test on this really small Drupal instance and then we have the unit test case which is the Classic unit testing to test actual code in the classes and then the newest one It has been added in Drupal 8.1 is a JavaScript test base So actually finally for the first time in years, we have a way in core to test JavaScript code and then there are third-party Testing frameworks, so there is a be have code exception and a tune and I want to talk a little bit about be had now to make a comparison So if you use browser test this stuff is so that this is functional testing So you test the functionality of the website, but the problem is it's quite slow The reason it's so slow is that for every test that will reinstall Drupal from scratch I do a full installation of Drupal So if you have like a website that has like 50 modules or something this can take some time It can take like a minute or two Just for a single test just to get started if you start to have like a hundred tests this will become very slow Then there is PHP unit This is unit testing so you're not testing the functionality You're testing the actual code that you've written and this means that it's very very fast. You don't need to install anything It's just like purely testing lines of code here, but on the other hand is very very difficult to write It's not suitable for a small project because you need to mock any dependency that your code might have and This will result you in like half of your development time will be spent on writing tests And this is the actual reason why many people think that testing for a small project is impossible Because I've experienced with unit testing and they know like okay It takes time to write these tests it takes a lot of time to maintain these tests and actually yeah This is really we don't have the budget for this, but then there is the third Solution it's like be had this is functional testing you're testing the end user functionality It runs really fast because it doesn't reinstall Drupal it uses you install Drupal once at the start of the test Sweet then it will run all the tests at the end of every test It will clean up the data that has been written. You might create ten nodes during a test at the end the ten Noiser Delete it again. This is good enough. I mean this is the thing that your website does anyway So clean up the notes then I start the next one It's a lot faster than installing from scratch and also these tests are incredibly easy to write So what's the solution? We use be had The be had Drupal extension. This is actually a plugin for be had this exposes our Drupal CMS and Integrated with be had we use a third-party Code hosting solution I get up kid lap or bid bucket kid lap you can host yourself as well it's open source and Use a third-party CI service. Don't maintain your own infrastructure because you will need to have somebody Taking care of us. You have to actually pay an engineer full-time to handle this It might seem in the beginning that you don't need to but this if you start using Jenkins and you will have to in the end and this will cost you your company about 80 to 150 euro per month this like Fixing a single regression for a client will cost you a lot more than this So this is this is about twice that you're looking at so we're getting finally to the meat of the Thing what you were maybe waiting for so be had what's be had so be had is actually it's not a really about testing It's a it's my behavior driven development and What's behavior driven development favorite development is actually a way of facilitating the discussions between the client and the development team And that's made might sound really vague and we're all using it for testing in the end anyway, but So what are we doing in behavior driven development behavior? It's like a sub branch of test driven Developments, you know, it's like you define a language which is shared between the development team and the client So the like a very typical example is the development team might talk about a feature and they're thinking about the features module While your client talks about a feature and they might think about a certain piece of the website that's in their mind called a feature and Like the time the developers can always have really technical terms for things the clients will have certain other terms But we will follow the client's language The client talks about something they call it the newsroom. We will not call it the news view We will also call it the newsroom So we will have we will develop the shared language and this language is Understandable by the client and by the development team and this language is completely focused on the business value So we will describe what the client wants in their project Well, you will see it in the examples later. Now behavior driven development also tries to solve the planning of the feature development and Yeah, the They do it by being based on the agile workflow. I mean this works really really well for everybody and It's similar to user stories. So be had behavior driven development uses the same type of Describing problems as the client is already doing in user stories and agile. So these tests look like user stories They're very familiar and also BDD provides the definition of ready and the definition of done We already covered the definition of done, but it will also Provide the definition of ready because we will have this user story and This user story will be written in a in a structured way And if we have this then we know what we have to build because it will describe I'm logged in as an administrator and I go in this page. I click this button and I will get a new news article All right, also The third and what I think is also very interesting is that this be had These be had scenarios will serve as documentation for the functionality that you have written So you don't have to take care of this anyway anymore because you will write the actions of the user down in a little script you do Certain actions on the web pages after and what's really nice is that okay You will have the full functionality of the website will be described in these texts And it will be completely up to date all the time Because if something changes the client as a change request, there will be like this test That's failing because it's testing the old functionality. So you have to update it You have to make you may keep it up to date that means this means your documentation will never be outdated it will always be current and This is also a really good basis for writing user manuals So if at some point you have a technical writer in the team that will provide the actual end user Documentation with nice screenshots and everything they can simply follow these step-by-step instructions and try it out really easily Oh, it works like this and then they can take their screenshots and write a nice text about it And the clients will be really happy now The way that this works is by a specific language called gherkin Now it's I think the one of the most inventive names for a language Ever this comes actually from the original Behavior-driven development framework was written for ruby and it was called cucumber when it was initially released It was quite a stir in the web development world because yeah, we suddenly had this new way of testing stuff That's really straightforward. And so be it is actually the PHP implementation of gherkin This is an example of how a test looks and gherkin or be had So we have a user story at the top We are we have a new feature so we give it a name the features product highlights Then we have a user story in order to promote specific products as a marketing manager I need to highlight products on the homepage and then we have a scenario. This is will be also our test Also, we give it a title the title is view product highlights Given I have three product highlights When I visit the front page, then I should see three highlighted products Okay, this might sound really stupid, but this is already testing something nice Like we have three product highlights in the database. They should be on the front page So when I go to the front page, I see them there. Now. This is a structured way of Describing this test and this is basically what girl. This is a whole definition of gherkin and Then not shall so we have a feature with a title then we have in order to Achieve a certain business objective As a user role or persona I need to perform some action and it's also quite important I think that these user roles and personas that you when you write these things you think of like a person and the Organization of your clients that you're writing this feature for because I very often see people writing like as a user of the website I should be able to see Product highlights on the home page, but in reality the user of your website doesn't care if there are product highlights on the home page the person that really cares it's like this Person that's sitting in the meeting and it's the marketing manager like They want to have the product highlights on the home page And if you use the right persona for describing this to you already like You're improving the relationship with your client. You know, it's like I'm building this for this person And then the scenario themselves so the test scenario is themselves They start with one of five keywords every line starts with either given Given a certain precondition exists on the website like given we have some data in the database when as a user I perform a certain action and I perform some other action then Something has happened which I can check so it's a testable outcome But something else should not have happened. I should not have any error message on the page or something like that And these five keywords actually and we had they're completely interchangeable So they're just checked if any of those five are there and they're not doing anything differently. That's quite interesting implementation detail Now luckily we don't have to write everything if we have if we want to test multiple data Oh, no, that's an excellent actually. Okay. This is a bit of a more interesting example So we can run a scenario multiple times with different data And this is called a scenario outline in In p-head and the scenario outline is indicated by this word Examples we just listed at the end of the scenario. So we have a scenario and then we have examples And then we have like a table which is written with these pipes and then the table has header Columns which are replicated in the test see so if I write read this out now So we have a scenario that shows a number of likes so we're implementing Facebook here So given I am logged in as a user When I visit the profile of one of my friends and I click on like then I should see a certain number of likes So the first time we were on this test. I log in a Cindy I Visit the profile of Cindy my own profile I click on like and I should see zero likes because I cannot like my own profile But when I log in as Thomas and I visit the profile of Cindy and I click on like then I have one legitimate like on the profile then the third time I log in as Thomas again I Visit the profile of Cindy again and I click on like again. I will still have only one Like because I'm not actually allowed to like a person more than once the third time We will log in as a different user Roger and we will go to the profile of Cindy and then there will be two likes and then the third and the last one is like okay Roger will be visiting the profile of Thomas and then he should also have one like so we have a very short and simple test The test of functionality and it actually can test Maybe a hundred line of lines of back-end go it already So this doesn't cost you a lot of time to think of to implement or to run This is very straightforward very cheap very good example also Be it as Concept of tables this looks very similar to the previous one, but we don't have the word example there This is a certain step and we just want to create more data more than one Entity at the same time at the beginning of our test So we can say given the following users exist and then we just provide a table with all the users This might be like 20 users Maybe if you want to check an overview and just like line by line by line just write them like this Then the code will iterate over that create all the users for you and at the end of the test They will clean it up again for you. So they will not exist anymore. So it's a really nice way of doing that then You can also add tags to these scenarios like there are two tags here that are very important to us is to all Developers so the first tag is the API tag This will actually unlock a piece of code that will allow us to use the Drupal API in our tests And we will need us for creating Users and entities and stuff logging in users So when we say given I am logged in as an administrator What will actually happen behind the scenes is that the beat code will do a call to Drupal And they will log in a user using the Drupal API and There is another tag that we can add if we add a tag add JavaScript to the top of our Scenarios and the test will actually run in a real browser using For example software like Selenium or phantom.js So they will actually launch Firefox or Chrome or another browser and run the test in an actual browser And this means that you can test your JavaScript functionality using p-hat I'm not going to show how to set it up because like Selenium can be a bit hard to set up on a system But if you want to do this, I mean you can find some blog post that explains how to set it up And this tag will unlock it. It's best if you don't test JavaScript Because you don't put the tag because running the test in a real browser makes it a lot slower to run All right now be had as a whole bunch of steps They call the steps of one line of test is called a step definition They have a whole bunch of steps built in so I have a few examples here You can see the whole list if you install be had and you type be had dash di. It's called step definition info You get a whole list of them There are more than 100 of them built in and these are typical things that that are offered given I am not locked in. I'm an anonymous user or I'm locked in as user with a certain name given I have Node of a certain no type with a certain title So this will actually create a node in the in the website and then you can test it You can visit parts. You can click on links. You can enter data in fields press buttons You can check that some text is visible on the website that some link is maybe not visible because the user doesn't have access and Yeah, there are more than 100 of these steps. So you can with these steps. You can basically test 99% of all the functionality that you need without having to write a single line of custom code in your test suite You can just install be had use this stuff and get on with your job All these steps are organized in what be had calls contexts So we have like a mink context mink is software which is driving the browser So it's like a translation layer between PHP and Selenium or phantom.js or Curl because you can also consider curl as a browser so you get HTML page from the website and parsed We have a whole bunch of Drupal steps Drush, you want to run drush commands in your tests. It's possible. You can check messages So if another message appears on the screen or a success message And then there is a final one which is called feature context And this is intended for your own custom code if you have custom steps that are specific to your project I'm not in the built-in ones then you can put them in there some examples Mink context will be interaction with the website because it's the browser driver So it will be visiting parts entering data and fields pushing buttons and stuff like this Drupal context will be very Drupal specific given the following languages are available giving the cache has been cleared, you know Drupal stuff Drush will be running drush commands message context should be I should see a success message and then feature context is your own custom stuff Then there are also subcontexts So if there is a subcontext is module specific There might be a module if you write the custom module for your client And you maybe want to reuse it later on in a different project Then you can add test step definitions which are very specific to this module if you have a news module you can say given I have the following news articles and then put a code in that Subcontext and one example that's out in Drupal.org is og menu for example to have a subcontext and you can write them for your own modules and an example of og menu so og menus of organic groups So it will put information about groups in menu So they will have a step that says then the navigation menu of the classroom group should have three links They have steps like this. So this is very module specific stuff All right to get started I'll go really quickly over this So in Drupal 80 you will need composer You need to be had Drupal extension because this provides the whole integration between Drupal and be had and you will have to write a configuration file, which is called be had to tell me Composer you can install it from the website. I'm not going to go into this because you should know this already There are other sessions about this stuff Installing the be a Drupal extension is done using composer. So you say composer require Drupal slash Drupal extension And once you've done that there will be a command line application for you available This command line application is called be had and it will be in a vendor folder. This is familiar to everybody. I guess Okay, and to see if it works you can just run the command on type dash dash version And then it will if it works everything is installed correctly. It will output the version of it You need to provide a be had to the amel configuration file This is pretty long But if you want to it's documented of course in the read me of the project So if you go to the Drupal extension project, you can see the full documentation there basically what you see You list the context that you want to use So you want to use the Drupal context main context and so on some of your own Then you see that the base URL is provided there because be had only be able to be able to talk to your Drupal side So you put your local host Base URL there and then also the route to the Drupal installation should be there because be had also needs to be able to talk to the API basically those are the things you need to customize in that and everything else can be taken on from from the basic one and Then you have a command to initialize a test suite So you have be had installed with composer and you can type the command be had dash dash in it And this will generate Scaffold a few files and folders for you. So you will have that will create a new folder The folder is called the features folder because a test in be had is called a feature. We are testing features of the website So they say okay our features are described here and It will generate an empty class for you We just called a feature context class and they invite you to put your own custom code in there It will be there. It has a the right It's the classes defined in there. It's empty, but you can start using that and Then you can just write a test you can start doing it So here is another example Anonymous user can see the news overview. So given the precondition is I have two news articles Given I'm not logged in and I visit the news path Then I should see the heading news and I should see the link article one and I should see the text the first article So I basically check that my news works and this is saved in the features folder which was created by be had in its command in A file and the file you give it whatever name you want and it ends in dot feature So the extension of the test is always dot feature Okay All right, and then you can run it So it's written you just type be had Vendor bin be had it will scan the current directory if it finds the features folder there It will run all the tests all of them Of course if you want to run a single one you can pass it as a parameter if you have like 20 tests written Maybe you only want to run one and then hopefully it will say that everything passed if something is wrong Then it will tell you it's like oh, yeah this step failed and It has some really nice plugins as well so you can take screenshots of the test running If something fails and like you see a screenshot that's written in your temporary folder so you can see actually what was wrong on the page Okay I'm almost finished with this some useful commands that you haven't be had you can do the DL dash DL Option to list all the definitions if you want to be reminded of the the way the user scenarios are structured with They have like a really funny Example test that we're just like from some James Bond stuff with spy agencies and things and Also, they have a command if you want to write custom steps Then you can just write your be a test and say like I give and I have three news articles And you can run the command be had with a pen snippets and it will actually create a little bit of code In your feature context, and you just have to complete that. I'm not gonna show it, but You can look into that. It's like scaffolding a little bit of code and That's quite nice Okay, if you want to be Try it out really quickly I Have maintaining a fork of the Drupal project Drupal project is like a composer starter kit for Drupal 8 websites And I made a fork of this which has be had built in not only be had it is also supporting the Drupal 8 test suite and it has PHP code snafender for testing your coding standards It has a good read me so it explains everything but basically you can install you can fork this project register on Travis CI Enable the project and Travis to I and you can Push code and it will immediately start running. It's everything is preconfigured there And you can just write the test and try it out and you will see like two minutes later You will see test results. So if you want to look into how continuous integration can work for you I invite you to have a look at this and I'm finally You will be very curious to see some real example codes of be had test because I just gave a small introduction of this Actually the be had triple extension itself has is tested in be had So if you install be a triple extension and look into their features folder you will find a whole bunch of tests there and also this is a project that I'm I've been working on with a team at the European Commission for the last two years We have tested our entire functionality in be had So if you go if you if you're curious about like what can be done and what how do these tests? Or maybe I'll have a minute left. I'll go through that so The project is called join up and it's on github so easy Europas European Commission Europa. I don't think the easy namespace was free probably So we have a test folder and then there you will find Hundreds of be a test and also the custom implementations Okay, I actually have five minutes Are there any questions or can I show you some example code? Maybe would be question Okay, so you're running be had test and something so the test says it's something that's wrong. Yes Yes, okay, so the question was how do you debug be had test so in be had you can Add a line you can actually add break points in your test by typing then I break What will happen the test will run up to that point and then in the terminal it will tell you please press enter to continue So the test will stop at that point and you can actually look at the website because I mean It's testing the real website and go to your news page and look at what's there So any if you want to figure it out more in detail You can put multiple break points, of course, and there is also a plug-in for be had we just called Be at step by step or something and actually requires you to press space every time for every single line It gets executed so you can really look at it running and then if you add a JavaScript tag You can see it running in a browser. So if you have Selenium running you see Firefox and It runs a test and normally it will go really quickly But of course if you set the break points and you can see the test running and see exactly where it goes wrong So that's really helpful to do that Okay, another question. Yes Yeah, you should not install test code on the production environment It's it's not intended to run on a production environment. So there might be security vulnerabilities in it It's like I suggest that you install it as a dev dependency in Composer So if you say composer install dash dash dev then it will be a dev dependency And then if you create a build for the production then it will not be part of it It will simply not be there and then there is no no I don't think there are any known vulnerabilities in it But I mean this is pure development code. You should not have run production. Keep it light Okay question. I had some discussions with people here that are trying to do stuff like this It's not like Fully hashed out yet, but there is like they were doing things like given I have this APK package Installed on my mobile device, which then allows you to push elements with like simulating fingers But it's not intended for visual regression testing Yeah, you you've shown some slide that showing the Comments of me at now and there were some placeholders and they seem to be very human Understandable. Yes is able to understand. I mean that the field is it they feel the machine name or whatever. I mean What kind of values should be put it depends on the context there? Is it working? It's they built it really In a really friendly way, it's I mean beard is really intended for you to write tests quickly So what it will do it will first check if a field exists with this the label name that you typed in there If it doesn't find a label with this human readable title Then it will look at the name or the title tag of the field if that's not there Then it will look if maybe there isn't a field with the ID that you gave so it actually checks multiple points and it will probably find the field for you and Also because we're integrating the Drupal. We know that okay We use this label for tag in HTML and then it points to the actual ID of the field so it works really transparently Yep, it will find it. Okay, any other questions. I think our time is over. So we have one minute Okay, I wonder if time to show anything. But anyway, feel free I'm yeah, if there are any questions left and you see me in the hallway tomorrow, then feel free to talk to me Thanks for the attention