I also rarely to TDD, because the paradigm of writing unit tests on front end components before writing the components just doesn't give me the ROI. On a CLI or an API server it makes sense, but for front-end it just seems like a lot of thrashing.
In short, I find it's a lot more work to write tests for front-end because I'm testing interaction, not only iputs and outputs.
Command line interfaces and APIs can be tested by providing an input and comparing the output to the expected output. Depending on the functionality of the service, you may also have some side effects to check for, but you would have an API design that is expected to match.
A front-end application ticket specification usually includes what the functionality and interaction should be, not what the DOM structure will be, that part is up to the dev. Testing the inputs, I find, gets a lot more complicated. I'm dealing with the DOM and triggering events on inputs and watching for classes or visibility chagning. Not only is the input and the end result important, but there are often lots of side effects to watch for too. I don't always know what the DOM structure will exactly look like before, so I would need to prepare the DOM result for the test before I write the code that I test. That usually results in having to update the test.
Granted, that's been my experience, your mileage may vary. If your experience has been to the contrary, I'd certainly like to hear about it.
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.
can you explain that?
+1. I don't understand what's the difference in developing a component on the frontend or a new controller on the backend using TDD.
Of course, thanks for reading
In short, I find it's a lot more work to write tests for front-end because I'm testing interaction, not only iputs and outputs.
Command line interfaces and APIs can be tested by providing an input and comparing the output to the expected output. Depending on the functionality of the service, you may also have some side effects to check for, but you would have an API design that is expected to match.
A front-end application ticket specification usually includes what the functionality and interaction should be, not what the DOM structure will be, that part is up to the dev. Testing the inputs, I find, gets a lot more complicated. I'm dealing with the DOM and triggering events on inputs and watching for classes or visibility chagning. Not only is the input and the end result important, but there are often lots of side effects to watch for too. I don't always know what the DOM structure will exactly look like before, so I would need to prepare the DOM result for the test before I write the code that I test. That usually results in having to update the test.
Granted, that's been my experience, your mileage may vary. If your experience has been to the contrary, I'd certainly like to hear about it.
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