So write tests first, decouple all the things and enjoy your work more. And by the way, I'm writing a book about all this stuff. So if you want to check this out, you can go there and see it there.
So, Marcus, thanks a lot for this. I'm not sure if you wanted to show us a bit more. Feel free to join our Q&A session, but at least you run Playwright. That's the best thing when you just have a problem, change nothing, run it again and it works. Yeah, I think that's right.
Okay, so let's start with our session. The first question, which is not a question, let's keep quiet in the back so people can actually focus on the talks. Okay, so just be a bit more quiet. Talk related question, why would I want to change my testing framework? Stubborn developer. Yeah, that's a good question. Usually you probably don't do it that often, but I see it in two ways. First of all, sometimes you do it because now, for example, you see Jest, the development of Jest, for example, slows down, and there are also ... For example, at my work, we are using Nightwatch Jest. Maybe you don't even hear about it because it's not really the newest thing, the trendiest thing anymore, so there are a lot of cases where I think you have or you want to switch test frameworks because although maybe the old one still works, but new developers want to use the new and shiny tools. They want to use Playwright instead of these old tools. So I think it happens quite a lot, and the second way I want to think about it is we also do database extractions, so we don't do SQL queries directly in our code because it's not that often that we actually change our database. It's probably the last thing we change, but it's still a good practice because it also enables us to be more flexible with our code. Totally makes sense. Once I wanted to switch from JESs to VTests and I just didn't do it because everything was coupled too tightly.
The next question. On our webapp, the bugs we had were really hard to cover with tests. We did not get bugs with UI. Our bugs were in frontend data processing. Are these not a good use case for testing, or did we miss a bit? I would suspect that you didn't write tests first because that's a typical sign. That was also a big problem with the application we wrote, that I told you at the beginning, is that our data structure was very complicated. We had a lot of global state, which made our whole application very hard to test. If you have problems covering those bugs with tests, then probably you should try to do more test first, more test-driven development, and then you might see the patterns that make the components hard to test.
Comments