-
Notifications
You must be signed in to change notification settings - Fork 6
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
Argument error when reporting results #1
Comments
Thanks @keathley I'll try and take a look today/tomorrow. |
I'm getting a similar error:
|
So sorry for the lousy experience guys, looking at it rn. |
@dnlserrano No worries :). These things happen. |
I just had a moment to look at this, I'll try and post more updates tomorrow, but gist of it is:
Agreed.
a) existing mutators are not enough to change the b) cover might not be picking up test covered lines it should be picking up; c) I might have some serious bug, or this might all be worthless. 😩 I hope not. 😭 Is this what open-source life looks like? 💔 Jk. I have to get out of the PC for now. I'll try to get back at it tomorrow morning. Thanks again for trying it out guys, it means a lot! And sorry again for the trouble you ran into. Don't give up just yet! Pretty please. 🤞 |
Ah and btw, I also had to tweak the file tree structure for your Maybe there is a better way of doing this. 🙈 |
* Also, add pattern match safe-guard to ensure module was compiled correctly, without errors. Relates to issue #1
If we weren't able to do any mutations, we should report back 100% mutation coverage. Or should we? 😈 Relates to issue #1
I've pushed another release, which should potentially fix some of the reported issues. I think right now option b) holds strong, which makes me think maybe I shouldn't be running code coverage at all before trying to mutate the code. But that's part a bigger discussion, I think (on the "To be done" section of the README). TL;DR I think is in You can try it out yourself with these changes @keathley. I default to reporting 100% mutation coverage when I mutate nothing, which seems like a good default for now (since ATM we know the lib is at a very young state to be able to raise red flags in such a scenario).
What do you guys think? Feedback is of course very much appreciated. Thanks again so much for giving this a go! ❤️ |
Did you guys get the chance to try it again? I have pushed some extra changes. Particularly, with I also got |
Closing this. |
Hey @dnlserrano! I tried this out on my norm library and I got an argument error from the reporter. It looks like its trying to convert a string to an existing atom and it can't find the atom or something similar. Here's the full output:
I'm running on elixir 1.9.1 and OTP 22 if that helps. I've also tested this with the most recent version of exavier on hex and with the master branch. The failure is non-deterministic and I suspect that just reporting whatever test it receives first since they're running async. I suspect that it would be safe to use
to_atom
here since this will really only be run in test mode and we don't really have to worry about DOSing the atom table. But I figured I'd leave that up to you.The text was updated successfully, but these errors were encountered: