DEV Community

Discussion on: What made you interested in learning how to write tests or how to TDD?

Collapse
panditapan profile image
Pandita

I've fixed so many bugs in one single app that I was wondering how to avoid them as much as I could. Talking about this to a QA engineer (who's also a friend) she told me everything about unit testing and let me know that most of the bugs I fixed were preventable with it (and probably integration testing but I haven't reached that point yet 🐌).

It took me a while (like, 2 years) to actually start including unit tests in our development flow... convincing is hard but, hey we're now doing it! \o/ I'm still super newbie with it, I'm terrible at inventing test scenarios, but I'll get there! There's always areas of improvement c:

Collapse
imforja profile image
João Forja 💭 Author

Congrats on convincing people to start doing unit tests! That's probably the toughest part of making the team adopt unit testing.

Regarding coming up with test scenarios, I find out that it becomes easier if I build my modules as units that have simple inputs and outputs. If I have a good grasp of the inputs, I can fiddle around with the possible values and define what the output should be. Of course, this approach implies that you'll need to organize the code to make it easy to test, which is good because code that's easy to test is code that's easy to understand. Hope this helps :)

Collapse
panditapan profile image
Pandita

aah thanks for the advice! much appreciated 💖 I'm also facing the problem that I don't really know exactly what to expect as an output because there aren't any requirements (sad I know), but maybe making the code much smaller than what we currently have might help. Thankies!! 😄

Thread Thread
imforja profile image
João Forja 💭 Author

Unfortunately, that's common, and it tends to be one of the core issues behind not knowing what to test.

Making the code the code base as small as it can be without compromising readability is an excellent approach to keep code maintainable. I'd say that it's one of those practices that we should follow almost always :) But this approach won't fix the situation :/

Usually, when we don't know what to implement, we should ask management or someone who should know that. The real problem comes when management doesn't know what needs to be implemented because the client also doesn't know what needs to be implemented! It might seem that the client is at fault here, but actually, it's just the way these things work, and the sooner we accept that, the faster we can start working on a solution.

Most often, the client has a general idea of what the app needs to do for it to benefit the business, and it seems quite well thought out when he talks about it. But as we start to develop three issues become apparent:

  1. The client kind of knows what needs to happen, but he doesn't know HOW the app should make it happen.
  2. We find out that we didn't entirely understand what the client meant.
  3. The idea that the client had of what the app needs to do keeps changing. The longer it gets to release something that real users can use, the worse the three issues above will get, and ironically, the harder it will be to release something that real users can use. And this is because we lack feedback/guidance from the real world, so everyone involved in making the app (from clients to devs) will get stuck in their heads trying to guess what the app needs to do to be a success. But we are awful at guessing, and it's easy for this process to keep going on indefinitely and burn through all the project's budget.

One solution to this problem is to simplify an application to the point where we can sit down with the client and easily map what's on his mind into inputs and outputs. Or in other words, we can write acceptance tests for the app. So if a client wants an app with 50 features, we might start with a single feature, or with degenerates of 5 the 50 features that we can figure out with the client how they'll work. Which approach to take will depend on which one leads to the shortest route to deploy something for real users because the goal is to get stuff out there as soon as possible. The faster we deploy, the sooner the client gets money, the quicker we get out of our heads and get guidance from the real world, and the more likely the project is to succeed. Also, there isn't a better way that I know of, to make sure that we're on the same page as the client than to show him/her a working application. After we have something working, it doesn't matter how minimal it is, the conversations start to become a lot more specific and a lot more productive.

Well, I ended up writing a bit more than I was expecting. The essence of what I wanted to say is that not knowing what to expect as an output of a test, can be a sign that there's a problem with how the project is being managed and that it is urgent to reduce the scope of the next release to the point that we can clearly define the requirements. Otherwise, the project will likely fail.

I hope that my mumbling is useful in one way or another xD

Thread Thread
panditapan profile image
Pandita

aaah thankies!! I can't go into much details regarding the project but I'll definitely try to use your suggestions in order to help ease the unit testing process. I appreciate your input a lot \o/ (though I guess you could use this reply as a blog post wink wink)

Thread Thread
imforja profile image
João Forja 💭 Author

haha thanks a lot for the suggestion. I think I'll follow it :D