Unitroller has FuseAdmin hardcoded into its bytecode inside of FusePoolDirectory causes issues with unit testing

[zerosnacks]

Midas Protocol has replaced the implementation with a dynamically constructed type(foo).creationCode + constructorData allowing you to pass in a fuseAdmin into the constructor.

Would it be feasible to replace our implementation where we have hardcoded the fuseAdmin address? @sriyantra
If not I can try to come up with ways that we can work around this limitation but it would mean that any tests we write are effectively integration tests.

https://github.com/Midas-Protocol/contracts/blob/a9c9f1d7d1c3106c545056d4af9105393aef29fc/contracts/FusePoolDirectory.sol#L144-L237

https://github.com/Midas-Protocol/contracts/blob/a9c9f1d7d1c3106c545056d4af9105393aef29fc/contracts/compound/Comptroller.sol#L1333-L1365

Related PR is #17

[sriyantra]

Midas Protocol has replaced the implementation with a dynamically constructed type(foo).creationCode + constructorData allowing you to pass in a fuseAdmin into the constructor.

Would it be feasible to replace our implementation where we have hardcoded the fuseAdmin address? @sriyantra If not I can try to come up with ways that we can work around this limitation but it would mean that any tests we write are effectively integration tests.

https://github.com/Midas-Protocol/contracts/blob/a9c9f1d7d1c3106c545056d4af9105393aef29fc/contracts/FusePoolDirectory.sol#L144-L237

https://github.com/Midas-Protocol/contracts/blob/a9c9f1d7d1c3106c545056d4af9105393aef29fc/contracts/compound/Comptroller.sol#L1333-L1365

Related PR is #17

I think the main issue here is compatibility with our current front-end setup. Let's see if there's a feasible workaround for now