DEV Community

Should I use Testing?

Vincent Tampos on March 11, 2021

Hello Everyone, It's my first time here posting in dev.to and I have been quite interested in implementing tests in my current JavaScript project....

Read full post

Spyros Argalias • Mar 11 '21

Welcome, nice to have you here :).

Well, one of the benefits of tests is that they tell you when something breaks. Ask yourself: when you write code, do some things break? When things break, do you immediately find out what broke and how? Or do things break which you don't notice for a while?

Tests help you because they show you what broke immediately. Then you can revert your code or fix it right away. If you think that will be helpful, then write tests, otherwise there isn't much point.

In addition, tests save you time... I'm assuming that after you code something, you spend a couple of minutes going on the browser and checking that things are working correctly. Automated tests can do that for you much faster.

In my experience, all projects benefit from testing, even if they're added late in development.

But finally, as a counter-argument, tests are difficult to get right. If you don't write them well they can actually make your project worse. Bad tests are a maintenance nightmare. They take a long time to write. They also take a long time to modify if you make changes to the code they're testing.

So overall, my personal recommendation is:

start learning how to test. If you're a complete beginner at testing, I recommend starting with a course.
if your project is a serious project that you want to release soon, don't worry too much about testing. Instead, add some tests after you learn the basics. Don't force yourself to add tests right away.
if you're using your project for practice and to improve your programming skills, then feel free to start writing tests immediately. It's all good practice.

Hope that helps. Let me know if anything didn't make sense or if I should explain something better.

Vincent Tampos • Mar 12 '21

Yeah, I'm the guy that tests the website right after I made changes in the code and I really liked that you shared your experience in counter-argument. Thank you! I'll look into cypress or jest as my starting point.

Pacharapol Withayasakpunt • Mar 11 '21 • Edited

Initially, I started testing in order to fit in the CI, and make Github commits never break things, even minor, again.

Be aware that there are different types of testing, though; including manual testing.

Vincent Tampos • Mar 12 '21

I haven't gotten into CI testing since I work alone on the project but I guess learning them would be great when I work on a project with a team. I'm also looking into automated tests :)

mikeyGlitz • Mar 12 '21

A great place to start in CI testing is to pick up a pipeline such as Travis or CircleCI. It takes a little bit of investment up front, but you save in the long run. Builds can be fired off from commits or branch merges instead of manually handing build and deployment. You can put your testing in a pipeline so your code doesn't deploy if your tests fail. Also DevOps is a great way to differentiate yourself as a developer, so building and managing pipelines see great skills to have

gkTim • Mar 12 '21

Welcome!

With unit tests you can check pretty easily if the software is still working correctly when packages are updated and often you find bugs you didn’t notice before when writing tests. Also it often leads to a better architecture.

But if you have a lot of code already and want to be sure that all is working e2e tests can be the faster way to go. Like with playwright or cypress.

But in my opinion unit tests are worth the effort especially in JS projects with no typing. It take some time to add them when you haven’t done it from the start, but if you have done the initial work new unit tests are added fast.

Jest watch mode or wallaby.JS for the win.

Happy Coding!

mikeyGlitz • Mar 12 '21

But if you have a lot of code already and want to be sure that all is working e2e tests can be the faster way to go.
Ideally you would want both unit tests and E2E tests. The unit tests verify functionality on a micro level. When I think of E2E tests, I picture starting the server up and running scripts which perform actions like sending API requests and validating the responses, or navigating to a web page and scraping the DOM to ensure everything is as expected.

Vincent Tampos • Mar 12 '21

I'm looking to learn jest / cypress but I haven't heard about wallaby.js, I'll look into it. Thanks!

guledali • Mar 11 '21

Should I write tests?

If I was doing testing for frontend, I would seriously look into cypress for most things and only reach for other testing framework for more logic related stuff. For example view-helpers in javascript that you have for formatting date and what not. Use jest or other unit testing frameworks for that.

guledali • Mar 12 '21 • Edited

It depends what kind of test you're written but you should make sure you writing meaningful tests. For example I have seen a lot react test that testing that the component renders that's it.


describe('Header', () => {
  it('renders the Header component', () => {

    expect(render(<Header text={ title: 'Foobar' } />)).toEqual('<header>Foobar</header>')
  })
})

I don't like those kinda of tests, I would prefer acceptance tests, for most front-end related stuff and reach for unit-test only when I need it

Scott Griffiths • Mar 11 '21 • Edited

Hi,

I believe that if they are going to add some value then they are worth adding/using. Most often I don't see the value in going back and retro fitting tests to existing code that 'doesn't get touched'.

For code that is actively build on its often good to have a strategy that touches on various areas of the SDLC lifecycle including unit, integration, functional and performance type tests to give you more breadth in what your testing might be able to expose.

As with everything this is context dependant, Ie : a highly critical application may need a lot more tests that a one page web app