Now we know most of our tools that we are going to use, but we still don't know what we're going to do with them.
Let's have a look at the features we want to implement into Yii Playground, and let's analyze the end-to-end structure of the final application and how we should meet our quality assurance requirements.
Given what we've seen in the previous sections, the base web app provided by Yii contains just a basic infrastructure with which you can start playing around. For the purpose of this book, we're going to add several features that in a real-world environment would normally be requested by the client or stakeholders on the project through a brief, discussed and analyzed by the internal teams and scheduled to be developed.
We are going to follow these steps and outline the necessary work needed in order to meet the desired level of quality assurance for the resulting application.
As previously said, the aim of testing is first and foremost to ensure that the code we produce matches the desired requirements. Anything else outside our code is not normally tested, but here exceptions apply and it really boils down to what the third-party code is doing, its overall quality, and reliability.
We are going to aim to change the basic app in order to be able to login from a modal window.
Once you've got the business requirements in place, we would break this feature down into subfeatures, if needed.
In fact, the path we will take on how to implement the modal window and the underlying infrastructure is quite important.
The code controlling the window from the client-side perspective needs to communicate with the backend to validate and authenticate the user. On a very basic level, this can be achieved by just adjusting the already existing controller that deals with the login process.
But we can do better. We can decide to roll our new login system without changing the existing one, thus avoiding introducing a breaking change that can affect our users. If for some reason a bug will slip past our control, we can just disable the new feature, while still letting the users log into the system.
This specific feature is also bringing up a series of implicit requirements, such as security and portability of our code, and integration with the existing and upcoming functionality. We want the user login application that sits on the client side to be self-contained and reusable as much as possible. Same goes for the backend authentication system.
The proposed approach is then the following, together with the high-level assurance criteria we need to satisfy, which will outline the scope of the work in much more detail when implementing it and, on the other side, will help us create the required tests:
- User REST interface to authenticate the user.
- Modal login window.
The REST interface will define some entry points to our application that will be easy to use. The URLs will then have a syntax of /resource/id/operation.
A GET retrieves information, a POST will store information. For example, POST user/login to log in, POST user/logout to log out, POST user/update to update some fields once if the user is logged in, and GET user/details to display user information.
The communication will work using JSON where needed.
Now let's piece together what we've done with the REST interface and code the JavaScript code that will open the modal window, validate the form, communicate the login credentials to the backend, and keep the user logged in until the browser window is closed.
As previously said, the code needs to be self-contained and portable, and for security reasons, it will not deal with any sensible information at any point, like the actual authentication.