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...
Collapse
 
suckup_de profile image
Lars Moelleken • 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');
    }

}
Collapse
 
d_ir profile image
Daniel Irvine 🏳️‍🌈

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 🤗

Collapse
 
aleksikauppila profile image
Aleksi Kauppila

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! 🍻

Thread Thread
 
d_ir profile image
Daniel Irvine 🏳️‍🌈

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?

Thread Thread
 
jessekphillips profile image
Jesse Phillips

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.

Thread Thread
 
aleksikauppila profile image
Aleksi Kauppila

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.

Collapse
 
axelledrouge profile image
AxelleDRouge

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

Collapse
 
d_ir profile image
Daniel Irvine 🏳️‍🌈

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.

Collapse
 
axelledrouge profile image
AxelleDRouge

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

Collapse
 
wolfhoundjesse profile image
Jesse M. Holmes

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.

Collapse
 
theodesp profile image
Theofanis Despoudis

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

Collapse
 
wolfhoundjesse profile image
Jesse M. Holmes

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.

Collapse
 
evgeniir profile image
Evgeniy • 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.

Collapse
 
prahladmishra profile image
Prahlad Mishra

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.

Collapse
 
codemouse92 profile image
Jason C. McDonald

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. ;)