On the Laravel News site there's a new post covering a new feature in Marcel Pociot's "Building a Chatbot" series (that makes use of the Botman package). This latest addition, a playground for testing and debugging bots allows you to get up and running without having to set up a complete environment.

Marcel Pociot recently launched a course called “Build A Chatbot,” a step-by-step video course on developing, extending, and testing Chatbots and Voicebots. Marcel is the author of Botman, a PHP chatbot framework for building chatbots.

Along with his Build a Chatbot course, Marcel launched Botman Playground, which provides a quick way to get started building and debugging chatbots without setting up a local development environment.

The playground allows you to set up a new bot, add commands and test the result with an included widget, all in-browser. The playground also allows you to set up connections to external services like Facebook, Telegram and Cisco Spark. The only catch is that you must be signed up for Marcel's Build a Chatbot course to gain access.

On the SitePoint PHP blog there's a tutorial posted that introduces you to Laravel Dusk, a browser-based testing tool, and how it can be used to test a Laravel-based application.

End to end testing for JavaScript applications, particularly single-page-apps, has always been a challenge. To that end, Laravel released its 5.4 version recently with a new testing library: Dusk.

With the release of Dusk, Laravel hopes to give its users a common API for browser testing. It ships with the default ChromeDriver, and if we need support for other browsers, we can use Selenium. It will still have this common testing API to cater to our needs.

The tutorial then walks you through the installation process and two approaches to getting it integrated into your application. They then create a first test, checking to see if a user can log in successfully. They also include how it looks when a test fails and the screenshot that's taken just before the failure. It also covers the testing of Ajax-related calls, inserting a delay when a button is clicked to wait for the response. Finally, the tutorial shows a more advanced example involving a popup modal, a form and multiple interactions.

On the Laravel News site there's an announcement posted about a new tool coming to the Laravel ecosystem - Laravel Dusk. Dusk is a browser testing tool that makes it easier to test Laravel-based Javascript-heavy applications.

When you write end-to-end tests, Laravel provides a set of useful helper methods which make it easy to click a link, fill an input field, or submit a form. Under the hood, Laravel uses the Symfony BrowserKit component to simulate the behavior of the web browser. However, if your app uses JavaScript and AJAX to load the page, BrowserKit will not work for you.

Laravel Dusk is a new tool that will be introduced in Laravel 5.4 to solve this problem.

The post goes on to talk about the tool and what kind of functionality powers it - a combination of ChromeDriver and the Facebook PHP-Webdriver packages. The testing process is claimed to be faster than normal Selenium tests and feels more "natural" than BrowserKit testing. Dusk will save screenshots of failures automatically and comes with helper methods, multiple window support and a Dusk-specific environment file.

The QaFoo blog has a new post today showing you how to use Mink with PHPUnit. Mink is a testing tool that allows you to write tests as if they were happening through a browser.

Another day for a short PHPUnit trick. If you want to use PHPunit to control a browser for functional or acceptence tests, then you can easily do this using the Mink library. Mink is well known from the Behat community to facilitate Behaviour-Driven Development (BDD), but it is a standalone library that can be used with PHPUnit just as easily.

This is more flexible than using dedicated browser abstractions such as Selenium directly from PHPunit, because you can switch between different implementations or even run tests with multiple implementations using the same code base.

They start with the command you'll need to get Mink installed via Composer (a simple require) and come example code for a test on the Wikipedia site (the page about PHP). They then refactor this a bit to remove the boostrapping of the Mink client into a reusable trait, making it simpler to use in other tests. They also refactor the test to use the trait and include the phpunit.xml configuration needed to run it.

Marcel Pociot has a new post on his site introducing a new tool he's created allowing for the easier creation of tests for your Laravel application: the TestTools Chrome extension.

Testing a Laravel application really is an easy task - the "Integrated" package from Jeffrey Way, that later got merged into the core framework is fantastic and helps you with the otherwise cumbersome task of testing and interacting with your application. But still - are you actually using tests?

A lot of times people really love the idea of tests, but simply don't get their asses up to start using them in their own projects. That's why I created a chrome extension that hopefully saves you some time when you need to test your app

He also includes an animation or two of the Chrome extension in action, showing you what kind of results you can expect. He does point out that there's some limitations of the tool including the fact that you can't really test a single-page application with it as it relies on the normal browser interaction points, not Javascript events.

The Paragon Initiative has posted a new tutorial that wants to provide you with everything you need to know about preventing cross-site scripting in PHP applications.

Cross-Site Scripting (abbreviated as XSS) is a class of security vulnerability whereby an attacker manages to use a website to deliver a potentially malicious JavaScript payload to an end user. XSS vulnerabilities are very common in web applications. They're a special case of code injection attack; except where SQL injection, local/remote file inclusion, and OS command injection target the server, XSS exclusively targets the users of a website.

[...] Cross-Site Scripting represents an asymmetric in the security landscape. They're incredibly easy for attackers to exploit, but XSS mitigation can become a rabbit hole of complexity depending on your project's requirements.

He introduces the concept of cross-site scripting (XSS) for those new to the term and provides a brief "mitigation guide" for those wanting to jump to the end. He then gets into some examples of what a XSS vulnerability could look like, both stored and reflected and provides the "quick and dirty" method for preventing them. He also mentions some tips in implementing your solution including avoiding HTML in your data if at all possible. He goes on to talk about the use of HTMLPurifier to prevent attacks, context-sensitive escaping (HTML vs JS vs CSS) and some of the browser-level features that help prevent XSS for the user.

There's a handy feature in the Symfony framework that provides a "debug bar" with information about the execution of your application. But what if you don't use Symfony for your development? Enter PHP DebugBar. This handy tool is easily installable via Composer and has lots of useful features including:

• Output of messages to the (Javascript-based) console
• Viewing exceptions
• Profiling database requests
• Showing an execution timeline
• Outputting the contents of the "request" (like superglobals)

It does all this completely independent of any other tool, so it's ready to drop into your application and go. You can find out more about the tool on the main project site or, if you'd like to contribute, you can find the project on Github.

On DZone.com Giorgio Sironi has written up a post about some testing he's done with the ""PHP Refactoring Browser" (more on that here) on some basic code examples.

IDE proponents love, in fact, an Integrated Development Environment that provides all the functionalities you need while writing and editing code; the followers of the Unix way typically write code in Vim while augmenting it via plugins where feasible and leveraging external tools that do one thing, and do it well. [...] Automated refactorings in PHP were out of the league of Vim and Unix users; thanks to Qafoo, however, a new open source tool is able to edit code with predefined refactoring recipes: PHP Refactoring Browser.

He goes through some of the basic features and functionality of the browser, setting expectations a bit. He shows how to get it installed (via Composer) and the results of some of his testing. Rather than including them all in the post, he opted to make actual commits on github of the changes.

On the QaFoo blog today the company is introducing a new tool to help PHP developers write better, more optimized code - the PHP Refactoring Browser (written in PHP too).

Without continuous refactoring, code maintainability and extensibility will start to decrease fast, even if it has tests. Until now, only IDEs contained functionality to perform automated refactorings. And then even only PHPStorm contains the most important refactorings such as "extract method". Today we release the PHP Refactoring Browser, a refactoring tool written completely in PHP. It is based on several outstanding open-source libraries.

The browser currently supports multiple refactoring methods including the extract method, renaming of local variables and converting a local variable to an instance. They include some example code and the result from the execution of the tool. The output shows where refactoring would work best with some color coding and formatting.

You can find more about this new tool over on its github repository.

Gareth Heyes has posted about some bypasses that he's found for getting around the XSS Auditor functionality in some browsers:

I had a look at XSS Auditor for a bit of fun because Mario said it’s getting harder to bypass. Hmmm I don’t agree. I seem to remember the same flaws are present from the last time I checked it with a little variation. It is also a very limited XSS filter not supporting detection of script based attacks (very common).

He includes three of his own bypasses - using a "formaction" on the submit input in a form, using "target" to override the iframe external resource restriction and the injection of a specially placed anchor tag. Each of these comes with a proof-of-concept example and another is also included courtesy of Mario Heiderich.