BDD & TDD in React

Hello, everybody. My name is Laura Beatriz. I work as a software engineer at YOD. And today I would like to talk about a pretty special subject for me. And that really changes the way that I write my tests in React application, which is TDD and BDD, specifically React.

So before starting, I would like to introduce a little bit about myself. I'm based in Brazil in the beautiful city called Florianópolis. The technology that I'm currently learning on and that I'm currently working with is mainly TypeScript, React, Node.js, JavaScript. I'm learning a lot of things about Python in order to, like, dive in some DevOps things, although I'm also really passionate about Elixir, so a lot of tools to learn.

Regarding to personal things, I'm really passionate about Harry Potter. And I love to play the violin. If you want to chat about any of these things, feel free to reach me out on Twitter or send me a message on LinkedIn. I would be really happy to answer all of you. And if you want to follow my projects, see what I'm currently working on, feel free to follow me or just see what I'm doing on GitHub.

So, before starting to dive into the topic, it's really important to see the summary of today's talk in order for you to gather some expectation and also for you to grab a cup of coffee before we really started to talk about it here. So, the first topic, it's just for us to go back in time in order to see where we are In the timeline from the testing queues along all of the years. So, along the years, we started to get better and better in testing queues and it really improved a lot the way that we write tests in React application nowadays. Testing practice overview, I will explain what is CDD and BDD in an overview, not in that overview, but for people that are watching the talk right now and are not familiar about it, why to use testing practice in React, when to use testing practice in React and the daily flow of developing a feature with CDD and BDD. Some disclaimers before starting. Testing is fundamentally related to software maintainability, so I don't want here to be explicitly and try to... So when we start to write tests, let's first implement a component skeleton, and then we're going to write test cases as to use to be later fulfilled. And then define different UI states according to user paths. So always try to create a balance when thinking of happy and unhappy user paths. And this is the screenshot showing how would I apply test cases. For instance, creating assets, scribe logs according to different UI states, success loading fader. When starting to implement tests, then we start to remove and deduce calls. And always remembering to avoid implementation details and resemble user actions as much as possible. So in the first test of the success state, we're going to render the skeleton for now. Try to find an element with a buttonhole and with a generate mem test and expect like wait for the synchronous request happens and all of the things and then make the assertion. Now implementing the code.

Let's try to write the amount of code to achieve, the minimum amount of code. We're going to refactor the code to improve quality and later maintainability and try to tweak some implementation issues to see if the tests are already catching it in order to avoid test regression.

We're going to then write the components. So that's the first draft. I've added some state, a handler, which is going to trigger the request in order to improve that in the third step of TDD, I'm going to rewrite the logic and extract the logic to a hook. So that's the final part of developing a feature.

And now I'm going to introduce the final takeaways of this talk today. I just want to make sure to pass the message that testing practices doesn't apply to all teams and projects. We have to be aware of what is TDD and what is BDD and see if it makes sense for us as engineers. Using the right tools to speed up test implementation is really important and we can see how much we're getting better at this along the years. Writing tests that resemble user actions enable us to ship software with much more confidence. And having the discipline to apply tests in practice is the key to achieve better results regarding architecture decisions.

So that's it for today's talk. I hope you all liked the talk. If you have any feedback, feel free to reach me out on social media and send me a message there. I would be really happy to answer all of you if possible.