How To Use TDD For UI Design 

I get the impression Dave is not much talking about Frontend development but TDDing around a UI. Correct me if I'm wrong. As a frontend developer actually BUILDING UIs in React and testing with Jest/React Testing Library (RTL), I often get into debates with my co-workers who don't believe TDD can be employed when building UIs. We tend to do the exciting thing first which is building the UI then testing afterwards using RTL to simulate the DOM and user interactions, but all this can be TDD'd. To TDD a UI, it's best to stop thinking about the UI as a visual thing (even though it is), but a behavioural thing. So forget about CSS and layout and test what happens when your user interacts with it. How does the UI change in response? What other parts of the system or 3rd party code does it invoke? Does it validate user input correctly? Treat the UI like a function: It has an input (props to the React component or an interaction e.g. button click or input change) and then it has a predictable output (a callback function [mockable] or a DOM element updates). With the inputs and desired outputs (behaviour) known, one can practice writing a failing test: Using a selector to select a DOM element (a button), perform an action (a click) and assert an output behaviour (a DOM element updated with text). Then implement the simplest UI code to get it to work, run the test again to see it go green, and then refactor the UI logic and test. Rinse and repeat. At this stage you're implementing UI business logic and once the test suite is done you can go and add styling and layout afterwards. These should not affect any of your tests because you're not testing pixels and colours and font sizing. For that you can use any number of visual regression tools or snapshotting (in Jest also). TDD is very do-able when actually writing UI code. Treat the UI as behaviour instead of art work. I find the UI code I TDD becomes more modular, leaner and easier to test, and no longer need to hack it to test weird edge cases.

TDD is 100% applicable to UI engineering. Outside-In TDD is great for that: - start with a failing E2E test that checks UI behavior as a user interacts with it (using a tool such as Cypress) - step down to the level of unit tests to implement component logic - make both tests pass - refactor - add styling to achieve the desired look and feel - move back to the E2E level and start again with another behavior It takes a lot of practice, but it's awesome! I've done it in personal projects and would love to do more of it at work too. Unfortunately, I do not always have the conditions to implement it

It works the other way round as well, UI developers can use the Adapter layer with a (drastically) simplified model of the business logic underneath it. Then use whatever tools you like to exercise the UI and test the outcomes in the model.

The hexagonal architecture is definitely my favorite model for software engineering exactly because of how it encourages that separation between the elements that "drive" behavior and the behavior proper. One thing I find helpful when thinking of UI is to bypass the idea of buttons, selects and other controls and simply look at UI interactions as one form of expression of user intent. My core code doesn't care if a user expressed their intent to purchase through a button click, an API call or a natural language message saying "complete purchase" - all it cares about is whether the intent was expressed and whether enough information was provided for the intent to be accomplished. I've also found it useful to not underestimate how complex the presentational logic can get, with things such as conditional form steps, A/B tests, etc., and then be careful to not get those concerns mixed up with the more business-relevant concerns in the code. I've learned the hard way how messy the development can get otherwise.

I'm currently developing software using the MVP (Model View Presenter) pattern to achieve UI testability. The Presenter serves as the adapter layer, similar to Dave Farley's example.

From a WPF point of view, what you're describing sounds like the ViewModel. As this object interacts with the UI through command bindings, and input/output through property bindings. So nice and clean for unit testing. The problem with testing UIs though is that the order of operations can not be assumed. So you either have to prevent a user from doing things out of your preferred order, oh be very resilient and not make any assumptions

It’s conceptually the same as any external component testing. That includes things like data stores, and services developed in-house. 1. Determine what the interface between your code and the external component looks like. 2. Ensure the the code under test interacts with the abstract interface and is not bound to a specific concrete implementation. 3. The concrete implementation used during a test is an appropriate mock allowing the test case to verify it uses the external component correctly. 4. The concrete implementation used in production is the third-party framework / external component.

Thank you for the video. I agree on the approach of considering the user as an interface like any other and testing accordingly. I'm a little disappointed though, because I was looking for an answer to my main challenge: TDD to make sure the user sees what they should be seeing, i.e. CSS. I still have no clue how to TDD that, as that's where the assumption "other people's code works correctly" breaks down. Something as simple as "animation-timeline: scroll(Y)" could be totally fine on one device and cause massively broken usability on another.

Nice shirt! Always looking forward to what you'll come up with.

❤ At long last! I've been waiting for this video! I've been doing this for a while but I'm not a software engineer and no one in my professional circle of engineers has ever mentioned this nor shown any interest when I did. I was hesitant to ask you guys directly. So glad when I saw this video. I confess when I saw the title I was thinking to myself "please say abstract layer please say abstract layer" 😂. I am become released!

I have been using an approach that I invented and works very well to TDD the ui. First I focus on developing the layout, in this moment TDD doesn’t help much and I create a completely static layout. Then, I start thinking about the behaviors of my page, I think about the first one, get the data from a server and renders the person name that comes from the server, I create a test for this that fails, so I change my static layout to make it pass and I continue doing this until my static page is changed to be dynamic and all the behaviors are implemented. Currently I am working with React, so I use Jest as it’s being straightforward to use TDD. What I realized was that for some kind of jobs, like layout creation, the TDD is not helpful and it slows the development, making it very difficult but to implement the logics the TDD is amazing, so I segregated the development in two phases: 1: Implement the static layout (without TDD) and 2: Make the layout dynamic with all behaviors (with TDD)

I agree totally with the "words" being spoken, but I think this goes over the head of the average React frontend developer when they have Jest tutorials a many to go off. This really needs a part 2 practical example in React (because it's the most prolific) as many engineers, including myself, benefit from visual examples. The one shown somewhat helpful, but the implementation is fairly outdated compared to modern frameworks (React, Vue et al). It's a hard sell to both the current and next generation.

can you talk about TDD for game development?

Thank you Dave!!!

I'm no TDD expert but I've been following the concept for some time and I don't see what's so special about using it for UI. Using Jest with JSDOM (which is a lot faster than spinning up an actual browser), you first write a test that queries elements on the screen, you simulate some user interactions, and asserts for outputs/changes inside the DOM. Then you start writing the actual UI code to make the test pass. Am I getting it wrong?

Most modern UI frameworks do not support this way of doing things (or very limited support). I wish they would because it would make testing a lot simpler. The fact is though, that vuejs/react/angular/etc are all view first frameworks. This is where the app is structured via components defined in the view. To enable the kind of abstraction you propose here requires a view model first approach, where the application structure is defined in javascript. You would need to write vanilla js or not use these frameworks. I think this is the reason why a lot of people in other comments are confused how to actually implement what you are describing.

Luckily some environments allow inspection of the UI (i.e. component tree). That makes it easier to make automated GUI tests without the need for 3rd party software. Java has the Robot class which comes with the standard libraries. I prefer to test websites by browser automation via Powershell. But you can do it also without a browser. Currently I'm working on a java based game but I started with lots of manual tests to check the behaviour, layout and thread behaviour (so that GUI events are processed correctly, resulting actions don't block updating the GUI, etc.). I will see how things evolve and to which degree I can automate the tests. Form based GUIs are much more simpler to test and automate. The tools my employer bought for GUI testing always had issues because they would just blindly trigger mouse or key events and the tests hung themselves up when dialogues and other unforeseen stuff popped up. Then I started experimenting on my own without the tools and made my own lightweight tools. The unit testing frameworks are agnostic to what you actually do. And it's just a matter of organisation to keep unit tests and other tests separate , as these take more time to execute.

Hi Dave! Great video as always. I have a quick question for you regarding testing UI. I''m writing a CLI application, which allows users to run JavaScript code but in the browser (kind of like node, but with chrome driver, to access DOM for example). I figured out a way to do that, and I start a http server in the cli app, run the driver, send the code to the browser, and it works. I also have websockets so my CLI tool also makes http requests to the driver. I want to do it TDD the right way. I find myself in a place where my CLI application in some situations needs to act as an http server (to serve content to the driver), and as http client - there are cases where that needs to happen simultaneuously. Now the question is, how do I write tests for that? Obviously, if I had to just write a http server, I would write write a test client, send a request, see a test fail, imlement the server, and the test passes. great. If I had to write a http client, I would do the reverse - I would write a test server, to be hit, and then I'd write the real http client to hit that in tests. That's all great. But what If i need both the server and the client in my application simultaneuously? It would seam that to write a server with TDD I need a client, and to write a client I need a server? How would you start coding that with TDD?

I like the way of Unit-Testing for Blazor. There's bUnit to test the individual components and it works really great.

Interesting, that’s about vanilla JS, bug how if we use some complex UI framework like react? How to make react components dummy and should we? How to wrap all this with unit tests?

When I see the words "UI Design" I think of a visual output (i.e. styling by a language like HTML or CSS). There can be logic and functionality written with languages like SCSS. I'm curious how this could be tested.

Can you show more examples please? E.g how do you do this in reactive style apps? E.g how do you mock chart libraries that draw to the canvas? What are some common examples that can easily be encapsulated? What are some harder examples?

Dave you should have worn your Space Invaders T-shirt for this one (you do have one, don't you?). Mine was stolen at the laundromat in 1980 or I'd send it to you. (Ref @7:56)

The general statement that the video makes is correct but some details would warrant further research. Jest is a test runner, not a UI testing framework. You can use it to test anything, say, a library or a backend, even something not written in JS. Cypress and Playwright deserve to be mentioned more than Selenium. Using Selenium these days is pure masochism. It's impossible to talk about UI TDD without considering React, the most used UI framework for new projects. React allows us to compose function calls to create a UI as a function of state, with some side effects. Even though there's a lot of magic happening in the background, everything we write in React is essentially a function. It takes some arguments, optionally fires off some side effects, and returns something, so it should be easy to unit test, right? Well, not quite so. The returns of React functions (components) are used by the framework itself, so they are not in a format that means anything to us. To learn how to understand the returns of those functions and perform assertions on them, we would need to understand the internals of React itself and risk having to update our assertions when the framework refactors its internals in a new release. React used to offer a utility for unit testing (react-shallow-renderer), but support for it has been discontinued because the maintainers think unit tests are useless. The modern approach is to use react-testing-library (aka RTL) which makes React renderer into a mock browser (facilitated by jsdom library). This is a good idea in general but falls short of the mark for two major reasons. First, the most popular test runners among frontend developers, Jest and its clone Vitest, are painfully slow. Coupled with the inherent slowness of fully rendering DOM into a mock browser, the advantage of unit tests over full browser tests is greatly diminished. Second, when a react-testing-library test fails, you get a dump of the HTML in a terminal, which can be horrible for debugging larger chunks of UI, and testing larger chunks of UI is sadly something that react-testing-library promotes as a good practice. My current favourite approach is simply not using react-testing-library and doing TDD with Cypress or Playwright. Starting a browser is no longer that slow, and there's a headless mode for CI (usable locally too if you wish). When tests are done the browser remains open and I can time travel through the test to see what happened. In CI, I can get videos and screenshots of failing tests. Logs are nice and user-friendly and there's no spam of warnings from React because we forgot to wrap an interaction in an act() call. What slowness exists can be reduced by cheating: mocking out the backend and skipping to states we want to test. TL;DR * Jest is not a UI testing framewok * Selenium sucks, use Cypress or Playwright * Traditional unit testing of React is a pain * Better to do TDD with UI acceptance tests

I agree with the approach as stated. I do, however, think that there is a hole from the standpoint of UI design. There is no way to drive your UI design with automated tests in the same way you drive code design with them. That is to say, the arrangement of UI elements is not something that can be cleanly driven by considering how you might test it. It’s a bit outside the scope of what this channel does, but I do think it’s an area worth exploring to the extent that some feedback mechanism is strongly desired to help uncover good UI design in an organic, self-driven way.

I'm not a big fan of mocking things out like this. There's a trade-off for the speed of feedback vs the confidence in the results, and you want to optimize for speed, but beyond a certain point, it provides so little confidence in the actual product as it would be delivered that it isn't worth the effort, especially once your tests start getting coupled to the parts of the interface (in the architectural sense) your users have no interaction with. If anything, from this, the principles of TDD tell us that reliable systems should have simple user interfaces, and the focus should be on testing the internal components, and optimizing how we test the UI, for example using tabs instead of launching an entire new browser window, interacting with the DOM instead of simulating keystrokes and mouse clicks, and using multiple cores for parallel tests. I use the Go library Biloba which was designed from the ground up with these ideas, and I'm able to execute dozens of cases per second, and this would be way more if I wasn't executing them on a decade-old machine.

"adapter - a thin, simple layer" I dissagree. My (limited) experience with UI development and attempts at writing fast automated tests make me believe that writing such adapter code often results in levels of complexity almost comparable to the UI framework itself. Especially if rich, UX-friendly, responsive UI is required. Which is why the selenium approach is often seen as cheaper compared to having to basically re-implement a custom UI framework. I think the only real solution would be for UI frameworks to actually start supporting automated testing as first-class citizen. Providing adapters and test fakes that emulate behavior of the real code for testing purposes. But that is not happening, as test automation is seen as annoying or unecessary.

Maybe this is a weakness in the full stack development concept. If UI specialists write backend code, maybe they are less likely to use TDD or even be aware of the importance of unit tests.

UI is a side effect, so hard to test

I’m a bit disappointed from the video. The whole point of TDD is writing the tests first, before you know what UI you will have. I understand the mentioned concept, but I don’t understand how to get the humble object with TDD. All in the video sounds to me like writing tests after you have the UI. My usual struggle with TDD and UI is, that I need to visualise the UI to see what I want. Does it fit nicely on the screen? Do I need to pop up an extra dialog, because that tiny edge case feature that most users don’t care about takes a majority of the screen? Can you read everything nicely? Do I need a button to do back or revert things? Does the layout look nice and intuitive? Do I need to change the order of input fields? All these questions I struggle to write tests for. Especially, before I know roughly the final design.

Testing UI? hm i have doubts that it can be done easily, sure there exist tools like SmartBear Test complete and Microfocus UFT, but really what people testing through UI? Right , business logic! So really people be professional , in my opinion testing strategy should be to test first business logic separately from UI. Now there maybe other professionals which would say it already hard work to test stuff and you suggest even more refactoring work for decouple from the direct access from UI ? Yes that's what i propose, your business logic is what makes money for your company, if you make it "hostage" to UI by hard coupling it , as some UI vendors propose , you make yourself dependent from them and rely on theirs "mercy". Of course It depends on your case, but decoupling is the way out of this cage and running UI tests is not fun, they breaking way to often.

IMO, TDD doesn't work well for all types of jobs such as 1) In Some works where the outputs can not be (exactly) predetermined e.g. research works. 2) In some works that require code -> test -> adjust loop for the program development e.g. some parts of UI or game developments. I think certain types/parts of UI developments could work very well with the TDD, but if some parts, writing the code first then testing later work better, I don't see the reason why we should insist on using TDD on those parts. Sometimes, people forget the whole point of the software engineering and use the TDD just for the sake of using the TDD. The fact is not in all types of applications you can finish the design before you write the tests, some works require your hands to get dirty, test, observe, adjust, and repeat to work more effectively

TDD for UI? Don't release anything until 99.99% of users can pass your tests. EZPZ.

When the desired outcome is not understood- no testing is beneficial. For coding is more of an art than an engineering. Until we make coding as boring as laying bricks, whatever DD is never a silver bullet, but rather GOLDEN COWs to which the priests (book sellers/authors/distributors/RU-vidrs) thus proclaim „This is our god, who brought us out of Egypt! Bow down and worship! Dance, drink and do all kinds of org***s“

The case was not made: just dismissing the function of an external library function that something that you should trust, is a bad rationalization. Perhaps they didn't make the test that they "should", and you cannot blame your own misunderstandings on the foreign library.

Hi Dave. I'm a big fan of yours, but I think I can show you a better way to do TDD on the front end. I reached out to you via a private message on LinkedIn. If you'd be interested at all in discussing this with me, please take a look and see what you think.