Hey Mark!
First of all, congratulations on the great article and for sharing your knowledge. I encourage automated tests as specification, documentation and quality assurance for any software. I love writing tests and I respect A LOT people who see the value of good tests.
Seeing your article, I couldn't help but comment some of my own learnings on tests.
I've had some very painful experiences with testing that led to learnings I'll never forget.
When I started getting comfortable with writing tests, my tests looked pretty much like those you write. They seemed like very good tests and I loved seeing them all pass in my CI server. With every new push, more and more joy of seeing those tests pass.
Until I had to refactor.
Think about a colleague of yours looking at this spec in a few weeks from now: 'should have a child component of type "Header" at "index" of 0'.
Let's say this colleague has to add a new feature, which is a breadcrumb that stays above the header. As soon as he implements this, this test WILL break and it won't say anything useful.
The header is still there, in the position your users expect it to be, serving the function it should be serving. But your relentless CI Server WILL reprove this commit and your colleague is going to have to change this spec just to make it pass.
Imagine it happening every single moment in every single change in the codebase with many many tests breaking, almost like the codebase was screaming. It's chaos.
Now, if you think about it, this spec doesn't say anything about your component. If you read it to the stakeholders they won't have a clue if that's right or not. You won't be able to use this spec to communicate with anyone involved with this software, except Enzyme itself.
There are several good ways of writing frontend tests that assert and specify something meaningful and very useful for the software maintenance and lifetime.
In your case, I'd start by reading some very nice stuff from Kent Dodds and taking a look at @testing-library/react.
I hope you find my comment useful and I'm eager to see you evolve in your engineering journey :)
Hi Pedro! I always find it hard what to write inside the 😃 it('what to write here'), do I use the method name of the method I'm gonna test? do I have to make the sentence longer so my teammates can understand or do I have to be more specific and be more technical?
But after reading your comment I finally understand that writing tests should be readable and should be easily understandable to another person specifically a teammate. I really appreciate your comment it helped me realize that writing tests and code should be the same they must be readable and should be easy so people can understand it.
I'm gonna try that library today. Thanks, man! Have a great day.
Hey Mark!
First of all, congratulations on the great article and for sharing your knowledge. I encourage automated tests as specification, documentation and quality assurance for any software. I love writing tests and I respect A LOT people who see the value of good tests.
Seeing your article, I couldn't help but comment some of my own learnings on tests.
I've had some very painful experiences with testing that led to learnings I'll never forget.
When I started getting comfortable with writing tests, my tests looked pretty much like those you write. They seemed like very good tests and I loved seeing them all pass in my CI server. With every new push, more and more joy of seeing those tests pass.
Until I had to refactor.
Think about a colleague of yours looking at this spec in a few weeks from now:
'should have a child component of type "Header" at "index" of 0'.Let's say this colleague has to add a new feature, which is a breadcrumb that stays above the header. As soon as he implements this, this test WILL break and it won't say anything useful.
The header is still there, in the position your users expect it to be, serving the function it should be serving. But your relentless CI Server WILL reprove this commit and your colleague is going to have to change this spec just to make it pass.
Imagine it happening every single moment in every single change in the codebase with many many tests breaking, almost like the codebase was screaming. It's chaos.
Now, if you think about it, this spec doesn't say anything about your component. If you read it to the stakeholders they won't have a clue if that's right or not. You won't be able to use this spec to communicate with anyone involved with this software, except Enzyme itself.
There are several good ways of writing frontend tests that assert and specify something meaningful and very useful for the software maintenance and lifetime.
In your case, I'd start by reading some very nice stuff from Kent Dodds and taking a look at @testing-library/react.
I hope you find my comment useful and I'm eager to see you evolve in your engineering journey :)
Hi Pedro! I always find it hard what to write inside the 😃
it('what to write here'), do I use the method name of the method I'm gonna test? do I have to make the sentence longer so my teammates can understand or do I have to be more specific and be more technical?But after reading your comment I finally understand that writing tests should be readable and should be easily understandable to another person specifically a teammate. I really appreciate your comment it helped me realize that writing tests and code should be the same they must be readable and should be easy so people can understand it.
I'm gonna try that library today. Thanks, man! Have a great day.
Great, Mark!
I see you have great coding skills. It'll be very easy for you to get even better at writing good tests.