Testing Q&A

[00:00:00]
>> Participant: Is just the recommended testing tool with most JavaScript and TypeScript projects?
>> Francesca Sadikin: I think so.
>> Participant: When you started working on the main code file, you wrote if else statement placing the previous implementation logic in that else block with the new requirements in an if block. So I'm wondering if it's good practice to do that, if the reason wasn't to ensure the previous code still runs.

[00:00:26]
My concern is if I take over the project with new requirements, it will it be good to follow the same approach putting all of the previous code in else block, and rewind in the if block.
>> Francesca Sadikin: I guess that was the way to create a seam in this project and in this particular code.

[00:00:50]
I think it depends on what existing code is going to look like for you. But the goal is to still somehow be able to write code to inject new bits safely and somehow let the existing system be the fallback. So if that looks like an if else block in your code or something else, however, way it can be achieved.

[00:01:23]
>> Participant: In this code base, there's a lot of if blocks, is there a way to refactor it, or is it just kind of to show the amount of cases with testing? Or what's the approach to making this code base better.
>> Francesca Sadikin: So it's interesting you're asking that. I am just writing the simplest amount of code and then just focusing on different aspects in different refactors.

[00:01:51]
Someone could continue going with this and continue refactoring it even more. That just wasn't the priority that I had here. So yeah, if someone wanted something different, they're free to do it. The important parts that I'm trying to show here is that with the test suite giving you immediate signals whether they'll come the code you're adding is working or not.

[00:02:20]
We can do many rounds of refactoring doing a little like goal each time. This is in contrast to maybe like taking all of these requirements and coming up with some sort of new perfect. Code to completely solve all the requirements and be the ideal code that you're looking for.

[00:02:45]
I found that when you do it that way, it leads to somewhat more complicated code, and it probably takes you a lot more time. And doing it in small little refactorings like this means that at any moment, if you had a huge deadline, you could ship it cuz it's working, right?

[00:03:04]
And then you can focus on doing more iterations to improve it continuously afterwards. So you don't have as much of a time constraint to make it the most perfect thing at the risk of it like that working.
>> Participant 2: I guess do you have any tips for when you're at an organization and you get assigned a ticket for a sprint and you hop in to add this functionality or debug this issue and you see an opportunity to refactor.

[00:03:34]
Do you have any tips for deciding when that's appropriate? Or when you might just have enough time to add the functionality and maybe continue with a pattern that you know is wrong versus deciding that this would be a good time to actually spend more time with factors.
>> Francesca Sadikin: So definitely will depend on how much time constraints you're actually working in.

[00:04:03]
But if you had a little bit of time trying to somehow create a new pattern in this code, you don't have to fix everything. But just creating a little bit of the new code and then encouraging all the other engineers to hey, when you add to this file, please work in this pattern now and let's stop adding to the debt.

[00:04:27]
That's probably most likely what you're going to do, because most engineers don't have the amount of dedicated time to completely rewrite it, yeah.
>> Participant 2: So, in that case, do you have tips for how you kinda leave that note there for the next engineer that comes along? If you're leaving it in an inconsistent state.

[00:04:52]
>> Francesca Sadikin: Yeah, it's interesting cuz in our current code base we do this, we have a lot of different states of code as well, and what we actually use is lint warnings. So we have our team writing custom ESlint warnings that says everything in this folder, don't add to this, we do not want to keep using this pattern.

[00:05:13]
So when someone opens that file, it'll actually show in a red underline at the top that says, that note, right? So, we find that those types of lint warnings are actually more effective than just putting comments because it's not as easily visible, yeah. Yeah, okay, so some takeaways, right?

[00:05:41]
Hopefully as you saw in this exercise when working with an existing code, with existing code base, if there is not a test suite. I really like adding a test suite one because It helps you understand the system right? Two, it's that immediate signal that tells you whether what you're doing is correct or failing a bunch of things when you're refactoring it.

[00:06:08]
And three, it acts as documentation for future developers. So I mentioned before that I don't recommend adding comments to code because it gets stale. Tests cannot get stale because they're usually run with every PR and every merge. And so it actually has a higher chance of being current with the code.

[00:06:35]
And it's always describing what it does, and other engineers can continuously add more tasks when they uncover bugs and stuff. So it's just like a live document of what this code is. I also covered just this concept of how do we try out figure out a way to add little bits of new code?

[00:06:58]
Safely without breaking a bunch of things, using seams and to refactor code in iterations. So that's a big one, it's like don't try and go after the most perfect code to handle all the cases all at once. That's just gonna take more time, it's gonna get really messy and working in little,little loops, still make sure that everything is working if you had to just ship it.