Naming Check

[startswithaj]

Hey @alexfertel thank you for taking the time to develop bulloak its very much apprecaited.

This is more of a question/issue.

Take the following tree

MyErc20::constructor
└── when contructed
    ├── it deploys
    ├── it sets the owner as sender
    └── it sets the name

Bulloak wants the test to be Called MyErc20, but the Contract we are testing is called MyErc20

If I call my test contract UnitMyErc20 bulloak will report on check

contract "MyErc20" is missing in .sol -- found "UnitMyErc20" instead

What is the best course of action here?

[alexfertel]

Hey @startswithaj ! Thanks for using bulloak.

contract "MyErc20" is missing in .sol -- found "UnitMyErc20" instead

Right, so this mainly refers to having different names in the spec vs the test.

If I understand correctly, you only renamed it in the .sol, but not in the spec. If this is the case, just doing:

UnitMyErc20::constructor
└── when contructed
    ├── it deploys
    ├── it sets the owner as sender
    └── it sets the name

Should suffice.

[alexfertel]

Do you think we should change the error message a bit? If so, how would you rephrase it to make it easier to understand?

[startswithaj]

Heya @alexfertel thanks heaps for your reply.

Nar nar your error message made complete sense. I understood what the issue is/was.

It just didn't feel semantic to write:

UnitMyErc20::constructor

or

UnitMyErc20::mint

It seemed better to write

MyErc20::constructor
...
MyErc20::mint
...

Because that is what we are testing.

And then have the file name as MyErc20.t.sol. Then inside the file have it MyErc20Test/UnitMyErc20...just to avoid the conflict.

I thought there might be some way are the start of the all the trees to give it the Test Contract name.

UnitMyErc20


MyErc20::constructor
└── when contructed
    ├── it deploys
    ├── it sets the owner as sender
    └── it sets the name

...

If we use UnitMyErc20 we end up having:

UnitMyErc20.t.sol
UnitMyErc20.tree

Where as I would prefer:

MyErc20.t.sol
MyErc20.tree

Hope that makes sense. Cheers

[alexfertel]

Ah, I see what you mean. That makes sense.

Note that the name of the t.sol is derived from the name of the .tree and not its contents, so I think the exact issue is having something that is not MyErc20 as the contract name. CMIIW.

The idea right now is that users follow Foundry's best practices which means that your test contract would be named MyErc20Test. However, I agree that it would be super nice to just use MyErc20::constructor vs MyErc20Test::constructor.

I don't have a good solution here, other than automatically appending Test to the contract name? Do you think that is a good trade-off?

This is also a breaking change, so I'd rather get this right, and publish v0.8.0, so this may take a while to see production.

[startswithaj]

Yeah I think what you are suggesting is ideal. We're on the same page.

FWIW, I actually found bulloak via https://github.com/defi-wonderland/solidity-foundry-boilerplate (https://github.com/defi-wonderland/solidity-foundry-boilerplate/blob/main/test/unit/Greeter.t.sol) and just cloned that repo to see if they get an error because I based my layout on that example. They do too:

I guess instead of it being a breaking change you could support both?

I'd love to see how others are using bulloak if you know of any other good example repos or public repos using it.

Cheers,

[startswithaj]

One other question, just while were in the swing of things if I could...

Take:

└── when passing an empty greeting string
    └── it reverts

Will generate a test:

function test_SetGreetingWhenPassingAnEmptyGreetingString() external

In the foundry best practices doc it says:

- test_Revert[If|When]_Condition for tests expecting a revert.

What would be the correct way to write the tree to get this test name?

Thanks again

[alexfertel]

FWIW, I actually found bulloak via defi-wonderland/solidity-foundry-boilerplate (defi-wonderland/solidity-foundry-boilerplate@main/test/unit/Greeter.t.sol) and just cloned that repo to see if they get an error because I based my layout on that example. They do too

Oh, interesting. Maybe they are open to tweaking the template after this is fixed.

I guess instead of it being a breaking change you could support both?

Well, yeah, we could add a flag. Need to think what that would look like, but it shouldn't be a big lift.

I thought of it as a breaking change at first, because we also want users to fall into the pit of success. I think this is small enough of a change (and fixable with bulloak check!) that a breaking change is fine.

I'd love to see how others are using bulloak if you know of any other good example repos or public repos using it.

The best example I can think of right now is CreateX.

What would be the correct way to write the tree to get this test name?

Try it should revert, like this:

└── when passing an empty greeting string
    └── it should revert