Was never a big fan of Test Driven Development on the frontend. I don’t think its really as applicable as it is on the backend. Generally on the backend, you define what your data model and what your api should return. Meanwhile on the frontend, you might have an idea of what the UI will look like, but you won’t know exactly how that’ll be implemented. Sure you could assume that you can select your button by its role, but it might not be the first button on the unit that you’re testing.
I would much rather implement my design on the frontend first, then if I get it right, just make a test for it and as you find edge cases while still in development, write tests for those.
If I don’t get it right, I’ll probably have a good enough foundation to start writing my tests.
With @testing-library/react the data-testid is your best friend when something isn’t easily selectable with: role or text.
My opinion will probably change on this. I’ve not used TDD much and I only just exploring it a bit. But I might also be doing more of a BDD
Recently for @Chainalysis I found myself struggling with a feature, so I wrote tests for what I knew worked, then wrote some failing tests describing how it should work but didn’t. And I found this to be quite a nice experience.
But I did realize mui to be quite annoying.
