ScopeLift / scopelint

An opinionated formatting and linting tool for foundry projects
79 stars 5 forks source link

feat: additional validations #10

Open mds1 opened 1 year ago

mds1 commented 1 year ago

Validate that:

radeksvarz commented 1 year ago

Would add to the tree for the spec besides functions:

mds1 commented 1 year ago

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

radeksvarz commented 1 year ago

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.