Sunday, June 5, 2022
HomeWordPress DevelopmentWhat are you testing? - DEV Group

What are you testing? – DEV Group


I’m having the privilege of working with individuals who shall be doing testing for the primary time.

Which means… this is a chance to watch people who find themselves programming for years, and but had by no means examined, be it for “lack of time”, or for not pondering it can be crucial.

Be it as it could… I’ll hold you posted.



What are you testing?

That is most likely the very first thing I’ve observed whereas reviewing the primary assessments on one thing that was “already working”.



Code is the legislation!

If you happen to’re testing one thing that’s “already working”, then that code is the legislation.

And try to be testing what it’s saying it does, and never what you assume or what you need it to do.
This might sound contradictory, however if you need your code to do one thing, then it’s important to even have strains of coding that implement what you need, or else, you’ll find yourself with one thing which may simply work due to luck.



Instance

We began testing an “UserCase”, which is the center man between the “Controller” and the Repository/Database.

class RepositoryExample {
    async getAll(someFilter){...}
}
Enter fullscreen mode

Exit fullscreen mode

class UserCaseExample {
    constructor(repository){
        this.repository = repository;
    }

    validate(someData){...}

    async run(someData){
        if(!validate(someData)){
            // simply an instance, do not throw plain objects round
            throw {message: '!!!', code: 42};
        }
        return this.repository.getAll(someData);
    }
}
Enter fullscreen mode

Exit fullscreen mode

class ControllerExample {
    async getArrayOfSomething(someData){
        const repository = new RepositoryExample();
        const userCase = new UserCaseExample(repository);

        attempt {
            return userCase.run(someData);
        } catch ({message, code}) {
            HTMLException(message, code);
        }
    }
}
Enter fullscreen mode

Exit fullscreen mode

I’ve tried to maintain it so simple as doable, however what would you take a look at within the UserCaseExample?



The primary attempt

// UserCaseExample.take a look at.js
class MockingRepository {
    constructor(){
        this.database = [...]
    }

    async getAll(someFilter){
        return this.database.filter(...)
    }
}

describe('Testing UserCaseExample', () => {
    it('Legitimate return of repository knowledge' () => {
        const uc = new UserCaseExample(new MockingRepository());
        const resultArr = uc.run('take a look at');

        count on(resultArr.size > 0 && Array.isArray(resultArr)).toBe(true)
        for (end result of resultArr){
            count on(end result).toBe(
                count on.objectContaining({
                    key1: count on.stringContaining('take a look at'),
                    key2: count on.any(Quantity),
                    key3: count on.any(String),
                })
            )
        }
    })
})
Enter fullscreen mode

Exit fullscreen mode

Whereas not the scope of this put up, there are some wordings that, no less than I, discover… unusual to say the least. This can come later, however be happy to debate the naming of mock objects, describe blocks, and take a look at names.

One other factor not in scope is the software you’re utilizing. We’re utilizing Jest and the lack of expertise about mocks, matchers, and the right way to use Jest API was clear. However realizing the software is one thing you’ll should study a method or one other and every software will differ. Once more, be happy how would you refactor the take a look at above if we ignore the primary downside.



The primary downside

The intent is evident. They have been anticipating an array and the take a look at is testing that they’re getting the array.

However, you see… the code is legislation, and in no second UserCaseExample point out an array.
As is, it merely takes the end result from the repository and passes it ahead.

Which means the take a look at ought to solely take a look at that no matter you cross within the repository is what you obtain again (which could possibly be an array, a null, or a string for all it cares).
You may also take a look at if the filter knowledge is being handed (and you are able to do it utilizing correct mocks).

If it’s vital that you simply obtain an array, then the answer can also be clear… change the code to replicate that you simply need to obtain an array.


I’m seeing that this would be the primary factor I’ll hold having to remind folks when testing:

What are you testing?

And I’ll hold saying that the code is legislation, so have the code “inform” you, what try to be testing.
And should you’re testing one thing that isn’t within the code… then it is best to change the code first!


Cowl Picture by Mufid Majnun on Unsplash

buy me a coffee

RELATED ARTICLES

LEAVE A REPLY

Please enter your comment!
Please enter your name here

- Advertisment -
Google search engine

Most Popular

Recent Comments