20 January 2020

Login Form TDD a UI Kata

User interfaces are usually considered hard to test, and people rarely develop their user interfaces using Test Driven Development. So it is considered hard. I like hard and I like challenges. I started to research the topic last year. Actually I went crazy. Besides my own experiments and practice, I hijacked most Coding Dojo and Coderetreat sessions and tried to TDD user interfaces with my pairing partners. I discussed the topic at unconferences and spent dedicated time with people in learning workshops. Besides its use I just wanted to see how far I could go.

This is the first article in a series describing what I learned. I spent more than half a year of my learning time on this topic and tried different approaches. In the past I found myself a different topic to research each year. Previous topics included Scheme and Architectural Refactoring. Currently I am investigating Splitting the Monolith. This makes me leave my research kind of unfinished - probably it is impossible to "finish" learning at all. I want to collect what I have learned during last half year before diving into something else.

The Exercise
To experiment with Test Driven Development of user interfaces, we need some UI to build. What would be a small UI that most people know? A login dialogue. I created a repository to drive the UI of a Login Form using TDD, the Login Form TDD UI kata. Your task is to create a Login window or form or web page. Here are the requirements:

Existing Code Back End
The exercise is focused on the front end part. Let's just assume an Authentication service, facade or end point which will be simulated in the tests. It has a method authenticate() to authenticate a user based on her phone, email or user name and her password. The call returns an AuthenticationResult which indicates success and an optional message for error situations. From now on the combination of a user's phone, email or user name is called the user's lookup. Under certain conditions, the UI logic will invoke this service or back end. Calls to the back end might take some time and/or block, so these calls must done asynchronously to keep the user interface responsive.

Requirements for the Minimum Functionality
  • There is a user name input field, which is limited to 20 characters.
  • The label "Phone, email or username" is left, next to the input field.
  • There is a password field, which is limited to 20 characters.
  • The password is either visible as asterisk or bullet signs.
  • The label "Password" is left, next to the input field.
  • There is a "Log in" button in the bottom right corner of the window.
  • There is a label in a red box above the button. It is only visible if there was an error.
These requirements are just describing the UI. The more interesting part is the logic. The logic uses the Authentication back end described above.
  • When user name and password are given, button "Log in" is clicked and the back end reports success, then the form is closed.
  • When user name and password given, button "Log in" is clicked but the back end reports an error, a message in the error line is shown and the form stays open.
  • While the back end is working, the "Log in" button is disabled.
My friend Thomas said that UI requirements need wireframes. So here is a sketch. Pretty, isn't it? ;-)

Bare Login Form Sketch
More Requirements
The goal of the kata is to experiment with driving the UI using tests. Maybe you want to ignore the styling (most people do) or ignore the visual elements completely. Or maybe you want to focus specifically on styling. Clearly we need more requirements like
  • More functionality while the back end is working
  • More logic in the view itself when username or password is not given
  • More UI elements like titles and logos
  • Detailed styling of all elements
  • Focus and tab order
  • Checkbox to show password
  • Caps Lock Warning
All these requirements and even more are listed in detail in LoginDialogRequirements.md inside the kata repository. The task is progressive: If you want more logic then go for more logic, for more styling add more styling. Thanks to Nick Babich, Software Testing Help and Anton Angelov this will be the most complete login you will ever build. Here is the styled sketch of the final Login:

Login Form Sketch of Everything Styled
Drive the UI of a Login Form using TDD
I created this kata to explore test driving UIs: login-form-tdd-ui-kata. Currently it contains code to get started in the following languages and UI frameworks:
  • Java/Swing
  • Java/Vaadin
  • Kotlin/Android
  • Go/raylib-go
  • JavaScript/plain browser DOM
  • JavaScript/React
Give it a try! If you do, please commit after each TDD step and share your repository so I can analyse it. Have fun!

No comments: