Lesson 9: Why unit test VRFCoordinatorV2Mock?

[ghost]

Why do we write the following test, when we didn’t build the VRFCoordinatorV2Mock?

it("can only be called after performUpkeep", async function () {
    await expect(
        vrfCoordinatorV2Mock.fulfillRandomWords(0, raffle.address)
    ).to.be.revertedWith("nonexistent request")
    await expect(
        vrfCoordinatorV2Mock.fulfillRandomWords(1, raffle.address)
    ).to.be.revertedWith("nonexistent request")
})

I.e. why are we unit testing a 3rd party library’s contract?

[krakxn]

Can you reply with the entire code? Thank you

[ghost]

For your first question: Well, Chainlink is a decentralized oracle - through which we receive data price feeds (in this case, ETH price feed), read more about it. (it is a very prominent protocol if you are not accustomed in the Web3 environment - valued at 3 bil. presently)

Thanks, but I never asked what Chainlink is.

Second question: "unit testing a 3rd party library’s contract?" We are not unit testing it directly - we are just testing if it works as how it is supposed to be for our purpose; it is not as if we are testing it solely, (we are essentially testing our Raffle contract to see if it works as intended, not a 3rd party's)

describe("fulfillRandomWords", function () {
    beforeEach(async function () {
        await raffle.enterRaffle({ value: raffleEntranceFee })
        await network.provider.send("evm_increaseTime", [interval.toNumber() + 1])
        await network.provider.send("evm_mine", [])
    })
    it("can only be called after performUpkeep", async function () {
        await expect(
            vrfCoordinatorV2Mock.fulfillRandomWords(0, raffle.address)
        ).to.be.revertedWith("nonexistent request")
        await expect(
            vrfCoordinatorV2Mock.fulfillRandomWords(1, raffle.address)
        ).to.be.revertedWith("nonexistent request")
    })
})

This unit test asserts that calling the VRFCoordinatorV2Mock contract's fulfillRandomWords function, with an address of a contract that hasn’t requested random words, fails, because the contract at the provided address didn’t request any random words.

Is that not directly unit testing a 3rd party library’s contract?

@PatrickAlphaC perhaps you could shed some light on your thought process here?

[krakxn]

Yep, we are - that whole encapsulation describe("fullfillRandomWords") is testing it in various ways. And in the quoted test "can only be called after performUpkeep" above, simply put, we are testing if the request returns a truthy value; if it is a falsy value it gets reverted.

Context: fulfillRandomWords fulfills the given request, sending the random words (first parameter) to the supplied consumer (second parameter).

Hope this helps

[ghost]

I appreciate you taking the time to try and answer, but you’re missing the point here. I’m not confused about what the test does, Chainlink or VRF. I'm trying to understand @PatrickAlphaC's reasoning for writing unit tests for Chainlink's mock contract. The unit test referenced here does nothing but test Chainlink's code. I’ve never worked with or come across anyone who does this in the web2 world, but I thought perhaps this is something web3 developers do for some reason. I'm not blocked here. I’m just somewhat curious to understand his reasoning for unit testing the VRFCoordinatorV2Mock contract.

[PatrickAlphaC]

@krakxn, thanks for answering here. I think you did a nice job explaining it.

Yep, we are - that whole encapsulation describe("fullfillRandomWords") is testing it in various ways. And in the quoted test "can only be called after performUpkeep" above, simply put, we are testing if the request returns a truthy value; if it is a falsy value it gets reverted.

@jav4di, sometimes, additional context is helpful when answering questions, and it looks like that is what @krakxn was trying to offer. Sorry their response wasn't clear to you. I agree with the rationale @krakxn gave.

We are not testing the VRFCoordinatorV2Mock itself, but we are testing that the VRFCoordinatorV2Mock can only be called after performUpkeep - it's more to make sure that the VRF will work after performUpkeep. We don't want our application to accept or generate random numbers before this. Now, I hear you, this still seems like it would belong to the @chainlink maintainers to write tests for this, but sometimes I take little educational liberties when teaching. You bring up a good point here though, and it's a nice catch, normally, this would be a bit extra to test... however...

Technically, it doesn't matter that @chainlink/contracts isn't owned by us. If you launch a smart contract in prod, and the package you download doesn't work as expected, guess who is to blame? Still you. If you want to get 100% test coverage, you'll have to test all your imported packages too. What if a package you import was hacked and malicious? You wouldn't want to use bad code!

Hopefully this helps, this is a great question.

[ghost]

I completely understand your reasoning in the case of imported code that the EVM will execute in production. But don’t our staging tests cover that? Unit testing an imported mock (which we'll never deploy to production) doesn’t make sense to me.

Though it sounds like you don’t see the following as unit testing the mock:

describe("fulfillRandomWords", function () {
    beforeEach(async function () {
        await raffle.enterRaffle({ value: raffleEntranceFee })
        await network.provider.send("evm_increaseTime", [interval.toNumber() + 1])
        await network.provider.send("evm_mine", [])
    })
    it("can only be called after performUpkeep", async function () {
        await expect(
            vrfCoordinatorV2Mock.fulfillRandomWords(0, raffle.address)
        ).to.be.revertedWith("nonexistent request")
        await expect(
            vrfCoordinatorV2Mock.fulfillRandomWords(1, raffle.address)
        ).to.be.revertedWith("nonexistent request")
    })
})

If I'm not mistaken, this unit test asserts that calling the VRFCoordinatorV2Mock contract's fulfillRandomWords function with an address of a contract that hasn’t requested random words fails because the contract at the provided address didn’t request any random words. In my mind, that is solely unit testing the mock's logic, none of ours. Please do correct me if I’m missing something here.

My question should’ve been more specific and clear, so thanks for your patience, @krakxn and @PatrickAlphaC.

[alymurtazamemon]

@jav4di I agree with you that chainlink must already have tested out that the chainlink nodes should not call fulfillRandomWords before/without calling performUpkeep. Good point! 👍

Patrick here has added an extra layer of confirmation, but you can skip this for your projects.