3 ms·

Unless you're writing super functional stuff, I don't understand how you could reasonably apply TDD when developing user interfaces: I target web, but the same

Unless you're writing super functional stuff, I don't understand how you could reasonably apply TDD when developing user interfaces: I target web, but the same could hold for mobile and other devices. Because, what exactly is the contract? Do I essentially write integration tests to the effect of "If I click input element with css class .username, type 'x', and then click input element with class .password, then type 'y', then click the button with class .login, the page URL has changed from <mysite.com>/login to <mysite.com>/profile?" There are no clear API interfaces for UIs. A user wouldn't really care that the button had class .username on it, for example -- that just gives us some way to identify the correct DOM element to perform the e2e test against. And some day, a developer could rename that class name, and it'd break the e2e test. In other words, I can't assumption what TDD looks like for user interfaces, without the whole testing process seeming extremely brittle. Contrast this with, if I call some REST API, I expect this response body. It's quite concrete.

rumanator 7y ago
> I don't understand how you could reasonably apply TDD when developing user interfaces: Unless you are trying to test whether clicking on a button or link fires an event, UI tests aren't exactly in the domain of unit tests.
eikenberry 7y ago
I don't think it is that much different, just maybe in proportions. In pretty much every application I write there 2 types of code. There is the guts or business logic that is written in the style of a library making it very testable. The other is the top level code, the 'main loop'. This is just there to hook together the library code in as short a way as possible. I think UI code differs in that it tends to have quite a bit more of this top level code that is basically un-testable except for very high level integration/scripted tests and QA testing. But UI code still has some amount of the library/logic code that can be written with testing in mine. I think this speaks to the myth that 100% test coverage is desirable and good. It is not.

rumanator 7y ago

> I don't understand how you could reasonably apply TDD when developing user interfaces: Unless you are trying to test whether clicking on a button or link fires an event, UI tests aren't exactly in the domain of unit tests.

eikenberry 7y ago

I don't think it is that much different, just maybe in proportions. In pretty much every application I write there 2 types of code. There is the guts or business logic that is written in the style of a library making it very testable. The other is the top level code, the 'main loop'. This is just there to hook together the library code in as short a way as possible. I think UI code differs in that it tends to have quite a bit more of this top level code that is basically un-testable except for very high level integration/scripted tests and QA testing. But UI code still has some amount of the library/logic code that can be written with testing in mine. I think this speaks to the myth that 100% test coverage is desirable and good. It is not.