You’ve heard of Test-Driven Development, but have you heard of End-to-End Test-Driven Development?
It will obviously revolutionize your workflow because it has more buzzwords.
I’ve decided to explore Cypress Test-Driven Development (Test-Driven Development using Cypress.io).
If you’ve tried to learn any web technology, you know how to make a ToDo app. But how do you keep track of all the ToDo apps you’ve made? Well, you need a ToDone app! We’ll use TDD to develop a simple ToDone app. First, we need a small test that describes one thing the user can do.
Obviously, our test fails because the ToDone page is empty.
Now, we’ll make the test go green. I whipped up some markup that satisfies this test (with some extra – keep reading for a rationalization). I’ll spare you the controller code, since I’m sure you can imagine what it would look like, and I ought to have unit tests for that class.
Boom, look at that! Our bar is now green. And we have a very simple app.
Now that our Cypress test is green, we can refactor. This is where Cypress TDD is a bit peculiar. Obviously, you should refactor your controller after its tests go green. But how do you refactor HTML? Since I’m not sure what refactoring HTML even means, why not add styling? Here’s what our ToDone app looks like with the new styles added.
Next, we want the user to be able to forget about some of their accomplishments. So, let’s add a new Cypress test to make that happen.
Well, now Cypress is angry because it can’t remove the ToDone.
After adding a button for each ToDone item, we now have a green test.
Just trust me, it all works.
And just like that, we have an accomplishment tracker app. Of course, there’s no persistence, but that just motivates you to do more things before you close your browser. And we’ve done this all with Cypress Test-Driven Development.
This summer I’ve learned a lot about TDD, and I’ve worked it into my development. I’ve found it useful when writing functions, but it’s hard to test-drive development in the front-end when I’m just writing markup. Cypress tests – as I’ve demonstrated in this blog post – allow me to use TDD to develop pages themselves.
Is it a good idea? I don’t know. I’m not sure what benefit I would get from doing End-to-End tests first. When I use TDD on unit tests, I feel like I’ve set up a foundation of confidence on which to make changes. In my limited experience, however, user interfaces – even sometimes their functionality – change more rapidly and drastically. Sometimes you re-think the whole thing. So, I’m not sure whether End-to-End test would benefit me that much when making a new UI.
Also, in case you missed it, I took large steps between tests. This is mainly because it’s hard to describe what a page should look like with Cypress. For example, I could have written a test that ensures the title exists, but that wouldn’t really be a useful test. So, I just added a title even though it didn’t have anything to do with making my test green. That is the big pitfall I see of Cypress TDD. One of the key issues when making a webpage is laying out where items should go. How do you test-drive that?
I probably won’t be writing Cypress tests first any time soon. I’m not entirely convinced it would be that helpful. But perhaps someone will read these words and sense within themselves a stirring to extend TDD to UI design. To that person, I wish you the best of luck.
Recent Comments