Agree with you, it might be more difficult, but not impossible and probably even not impractical.
You are right, implementing the complete test in detail might be difficult, but what you always can do as a first step is writing down the expectations. E.g. you can use the gherkin language to write what should happen in natural language, without focusing on the details what button is to be clicked or what input field to be filled, you define the expected behaviour.
That would not be TDD, but more BDD, but the goal is more or less the same.
In a second step you could even implement the test, including an imaginary DOM structure. If you use page Objects, then changing the DOM should not be a big issue.
Agree with you, it might be more difficult, but not impossible and probably even not impractical.
You are right, implementing the complete test in detail might be difficult, but what you always can do as a first step is writing down the expectations. E.g. you can use the gherkin language to write what should happen in natural language, without focusing on the details what button is to be clicked or what input field to be filled, you define the expected behaviour.
That would not be TDD, but more BDD, but the goal is more or less the same.
In a second step you could even implement the test, including an imaginary DOM structure. If you use page Objects, then changing the DOM should not be a big issue.
I even argue that you should write tests for buggy behaviour, before you fix it dev.to/jankaritech/should-you-writ...
thanks, I will have a read.
I haven't come across gherkin yet, I'll have to give it a look.
have a look at it, its a great tool to write expectation and BDD for JS you can use cucumber-js to interpret it github.com/cucumber/cucumber-js