Open mds1 opened 1 year ago
Would add to the tree for the spec
besides functions:
Hmm interesting, so the spec would include when certain errors/events are expected to be thrown/emitted? Do you have a sample UX in mind for this? I've been thinking a bit about how to make the spec-structuring more flexible and expandable, will create an issue with some ideas next week, so curious to hear more about how you see errors and events fitting in to scopelint spec
Indeed this is better to be thought through.
A) One perspective is that errors and events are part of the interface besides functions. So there are requirements in some spec on those as well. When doing unit tests here I typically have to answer whether "Do I emit the event / error correctly? with correct arguments?". This is in line with adding them to the tree. And is easier to implement now to scopelint.
B) The other perspective is that errors and events are product of functions and so the requirements are covered within requirements on functions.
Testing for the latter case rather answers the question - "do I cover all the situations when this error / event shall be emitted?" Or is there any situation forgotten?
That could be visualized by the different output - matrix / table of functions vs erros+events.
Validate that:
camelCase
src
andscript
directories arecamelCase
PascalCase
.s.sol
files in the script directory — done in https://github.com/ScopeLift/scopelint/pull/9function test*
methods areinternal
orprivate