On November, 21 2019 14:00 PM (EST) I'll be giving a presentation on vuemeetup.com
It will be about agile development with Vue, and in preparatio...
For further actions, you may consider blocking this person and/or reporting abuse
can you explain that?
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
+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.
I like the way you wrote this and I agree with the way you see this subject.
I wrote something similar recently
dev.to/parsyvalentin/piece-of-mind...
Hope you'll see something interesting.
Hope to read you again soon.
I've been trying to take a more TDD approach lately and it's still kicking my ass.
I really relate to this, I tinker so much while building out UI that I feel if I did write my tests first I'd just be updating them twice a day because I changed my mind about what a certain element should show/do.
Glad you can relate, I just want to point out that by putting it off I am (we are) taking a risk that when it is time to release and I write the tests when the functionality is no longer fresh in the mind, so the test might not have as good of a coverage. It's important to be aware of risk/benefit.
Great honesty about how/why you approach testing.