New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
API for writing tests for lints #516
Comments
You are meant to be able to do |
Okay, it did work correctly! Awesome. There are a couple of minor problems:
I'm planning to write several tests combining stuff across modules and it seems like I'll end up writing more imports than test code 😅 ... One of the rules files can be found here. |
I fixed the issue with Yes, you need to duplicate imports, by design. The reason is that different tests will want different sets of imports - but I can see why it's a hassle for you. I guess if I'm honest I probably wouldn't do overly much testing of the rules you are adding - the rule pretty much speaks for itself - and any misunderstanding that breaks the rule is likely to be reflected in the test. I don't add new tests with new rules in hlint.yaml. |
I agree that the examples I've shown here are a bit silly. However, once I add more stuff, I don't want to accidentally have lints that don't work ... it would be very hard to track those down if there's a mistake as users may not even know that there is a lint for X and I'm not going to be using all the packages on Hackage :). I understand that you may not have the time to implement support for an alternate system for imports, but if you are open to the suggestion, let me know and I'll try to submit a PR in a few days. Closing this issue for now. Thanks! |
I guess I'm curious what mistake you envisage making in the hint and how the test will catch it? That might direct what features are needed. |
Hmm, here's a complex example that I just tried out:
I wasn't certain that the double-matching on Then I tried:
and it did work as expected. I can't come with a better example off the top of my head right now but I recall writing a lint for some After that, I've felt wary of writing lints without small test cases. The thing is, even if something in your application blows up, you may go and ask "hey why didn't our test suite catch this earlier" but you're probably not going to your linter and check whether there was a lint for it that may not have fired. Anyways, sorry for the rambling story, it isn't really a big deal. The big deal is being able to run the tests easily if I want to and that does work without hiccups :D. |
It feels very wrong to dissuade someone from tests... Perhaps some special syntax in an annotation should lead to that portion being copied into all subsequent annotations in that file? Perhaps \ at the end (rather than ) should be continue and accumulate? What do you suggest? |
I don't quite understand. Could you give an example? Perhaps something like the following?
|
OK, I prefer your idea. How about:
With the logic that everything in |
Yep, that works as I'd expect. |
Do you want to hack up the code? If not, I'll try and get round to it. |
I'll send a PR in a few days (it isn't urgent), working on other stuff ATM. |
I'm working on a repo so that we (the Haskell community) can share lints for commonly used packages. I'm hoping to announce it on Reddit etc. once I've solved typesanitizer/hlint-roller#1 and typesanitizer/hlint-roller#2 .
To make sure that the lints work, I'd like to write tests (issue 1). The thing is, I don't want to duplicate a bunch of logic which you already have here, for example all the stuff needed to run the tests under data/hlint.yaml.
Would it be possible to expose a small API for writing tests for lints? If yes, I'm happy to contribute a PR if you can provide guidance on what would need to be changed.
The text was updated successfully, but these errors were encountered: