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){...}
}
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);
}
}
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);
}
}
}
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),
})
)
}
})
})
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