DEV Community

Do devs really need to test?

Daniel Irvine 🏳️‍🌈 on January 29, 2020

In my last post I talked about ideas for convincing devs to do more testing. However, perhaps what I should have addressed is the topic of why do d...

Read full post

Lars Moelleken • Jan 30 '20 • Edited

Hi, Acceptance-Tests is what you are looking for. :)

add some helper css-classes into your dom (test-, js-, ...)
and run the tests in headless-chrome in you CI server

e.g. via codeception.com/

<?php

final class UserTemplateAcceptanceCest {

    /**
     * @return array
     */
    protected function userTemplateProvider()
    {
        return [
            ['kunde_id' => 45127002, 'templateName' => 'Foo' . uniqid('Foo', true)],
            ['kunde_id' => 45127003, 'templateName' => ''],
            ['kunde_id' => -1, 'templateName' => 0],
            ['kunde_id' => 0, 'templateName' => 'FooBar' . uniqid('Foo', true)],
        ];
    }

    /**
     * @dataProvider userTemplateProvider
     *
     * @param \AcceptanceTester    $I
     * @param \Codeception\Example $userTemplateData
     *
     * @return void
     */
    public function testCreateTemplate(\AcceptanceTester $I, \Codeception\Example $userTemplateData): void
    {
        $I->wantTo('Create new user-template.');
        $I->amOnUrl($I, UserTemplateDetailsView::getUrl(['element_id' => 'new']));

        $I->waitForElementVisible('.test-PageTitle');

        $I->fillField(['name' => 'templatename'], $userTemplateData['templateName']);
        $I->selectOption('kunde_id', ['value' => $userTemplateData['kunde_id']]);
        // ...
        $I->clickWithLeftButton('.test-HtmlFormExtendedSubmitButton');

        $I->canSee($userTemplateData['templateName'], '.test-HtmlTableContent');
    }

    /**
     * @depends      testCreateTemplate
     *
     * @dataProvider userTemplateProvider
     *
     * @param \AcceptanceTester    $I
     * @param \Codeception\Example $userTemplateData
     *
     * @return void
     */
    public function testDeleteTemplate(\AcceptanceTester $I, \Codeception\Example $userTemplateData): void
    {
        $I->wantTo('Delete created User-Template.');

        $I->waitForElementVisible('.test-PageTitle');

        $I->fillField(['name' => 'usertemplate_id'], $userTemplateData['templateName']);
        $I->clickWithLeftButton('.test-ButtonIconSearch');
        $I->waitForAjaxWithSpinner();

        $I->clickWithLeftButton('.test-SelectAllElements');
        $I->clickWithLeftButton('test-Act' . StammdatenUserTemplateListChangeListDeleteAct::class);

        $I->clickWithLeftButton('.test-ButtonExecute');
        $I->acceptPopup();

        $I->cantSee($userTemplateData['templateName'], '.test-HtmlTableContent');
    }

}

Daniel Irvine 🏳️‍🌈 • Jan 29 '20

Thanks for picking me up on this 🤣 I don’t disagree with you. Deciding what to test and at what level is one of the hurdles that trips people up. Overtesting is a serious problem. For unit tests I usually avoid testing anything ”static” like HTML or CSS. Those are tests that I’d rather leave to QA, or write up as system/acceptance tests in some other way.

To come back to my statement... yeah, there’s a huge assumption hidden within it, I‘ll see if I can find a way to make that clearer, as discussing how to test well is waaaay beyond the scope of this post 🤗

Aleksi Kauppila • Jan 29 '20

Overtesting is a serious problem

Does this really exist? I would be interested in hearing some examples. 🙏

I can definitely see a problem in time spent in testing. And that is most likely spent in manual testing because of not having knowledge on how, on what level and what exactly to test.

Thanks for a great post! 🍻

Daniel Irvine 🏳️‍🌈 • Jan 29 '20

It might be something I’ve just dreamed up, or maybe there’s a better name for it, but here’s how I think of overtesting.

Overtesting is what happens when your write tests that cover more surface area than necessary. One way this happens is relying on end-to-end tests instead of unit tests. Greater surface area means more chance for tests to break when code is changed. In other words, you get brittle tests.

Hopefully that makes sense?

Jesse Phillips • Jan 30 '20

Each test is additional code which must be maintained. If the tests need to be updated with every code change, even though the functionality they are expecting to test isn't changing, it becomes a liability.

Clearly that isn't because there are too many tests, but it kind of is. The mantality this come from is that every test is valuable. While you could write another test, clearly this is covering more and may find an issue it just isn't this time.

Aleksi Kauppila • Jan 30 '20

It makes!

I think this is due to focusing the tests on the wrong level.

Too small or inappropriate details are verified in a test that is done by eg. Calling the service over HTTP.

AxelleDRouge • Jan 30 '20

Thanks I quite agree with you.
In my current job, I often am the only dev front-end, with no QA (what's this ?? not sure that my manager even know the term) so I have learned to appreciate a lot TDD and testing.
But while I am getting better at unit testing, I still have a lot of difficulties understanding the methodologies, like how to correctly use mocks, or the functional and e2e tests. It really is a whole part of the job, I just don't have the time and ressources currently to learn it (and of course, no one to learn it from) so I am sticking to unit testing, for the moment, until I can learn more.
If someone has good ressources on the subject, I would thank you for it

Daniel Irvine 🏳️‍🌈 • Jan 31 '20

The best way to learn (IMHO) is to work with others who REALLY know how to do it. I had been doing what I thought was TDD for 5 years before I joined a TDD consultancy. I was lucky to have colleagues who helped me improve. So if you get the opportunity to pair with experienced TDDists then I suggest you take it. You’ll learn so much. One way may be to join a local coding dojo meetup or software crafter meetup if you can find one (see softwarecrafters.org).

Since you’re a front-end dev, you might also be interested in my book, Mastering React Test-Driven Development. It covers unit testing and also acceptance testing with Cucumber and Puppeteer.

AxelleDRouge • Jan 31 '20

Thanks a lot :)
I probably will buy your book (today, before Brexit XD) It seems exactly what I need thanks. At it probably will help in my company

Jesse M. Holmes • Jan 29 '20

Newsflash: QAs are better at testing than devs are

This. Our QA often thinks of scenarios I would miss. She's the heroine of this story.

Theofanis Despoudis • Jan 29 '20

Does that imply that we should offload all of our testing effort to QA's? No

Jesse M. Holmes • Jan 29 '20

Yes, please don't dump your buggy code onto QA because you think it's their job to find problems. What I was trying to say is that I learn new things to look for every time QA finds something.

Evgeniy • Jan 29 '20 • Edited

End-to-end test for success path if there`s no complex logic.

Separate QA for checking that code works is anchor that slows down processes.

Tested code is simpler than untested code

Now, that is a bold statement.

Statement above is about unit-tests.

Prahlad Mishra • Jan 29 '20

Agree with you, but getting it to the habit of other team members is a long shot. I am trying to guide by example and hoping some day unit tests with high coverage would be the requirement instead of optional.

Jason C. McDonald • Jan 29 '20

We require tests as part of revisions (think Pull Requests) in our company workflow, and they're reviewed as part of the code accordingly. If you don't know how to write good tests, learn how. ;)