Hi guys. I have made an open source extension method that uses Shouldly. It asserts that the Body of an IHttpActionResult response for a .NET api has some expected fields. Right now it's called BetterBe. But it is pretty cool. Here is the link to the project. It is called RIDGID.Common.Api. The above picture is what you can do with it. This is just an idea blossoming at the moment. But I think there would be a cool feature in store for Shouldly where it would work on ActionResult's for API's. It would deserialize the body and whatnot then do reflection over the object and assert that the value is what is expected.
For example:
Right now it is baked into a error message project that adds error ID's to responses: https://github.com/RIDGIDSoftwareSolutions/RIDGID.Common.Api
The actual main logic of the file is here though: https://github.com/RIDGIDSoftwareSolutions/RIDGID.Common.Api/blob/master/src/RIDGID.Common.Api.TestingUtilities/ActionResultBetterBeExtension.cs
If you are interested please email me nfgallimore@gmail.com
I just came here from https://up-for-grabs.net to help out with some open source projects, and shoudly is one we also use in our company. When coming here there were several issues open and tagge as jump-in, but most issues were already solved. If you are searching for people to contribute, I would be grateful if you could do some house keeping and close already implemented issues which are marked as Jump-in. This would decrease the amount of overhead from people willing to contribute but unwilling to sift through every issue to check whether it has been implemented
Hello, I've been using Shouldly for some time now, but lately with my (dotnet core) projects the failure messages are not as good as before. The name of the variable is not put anymore in the message.
for example for
employee.FirstName.ShouldBe("John"); // fails
--> message: "Dale" should be "John" but was not
My question: is that on purpose or did I miss something? This is not in line with the documentation I think.
for example for
employee.FirstName.ShouldBe("John"); // fails
--> message: "Dale" should be "John" but was not
My question: is that on purpose or did I miss something? This is not in line with the documentation I think.
(it kinda diminishes my point when I try to convince people to use it :-) )
Hello, I've open-sourced a utility for generating Shouldly tests, it's at: https://github.com/alansingfield/UnitTestCoder
Hi, I am a .NET developer, working mostly on commercial apps, and I would also like to contribute to open source. I think shouldly is very nice project, I like the assertion syntax you invented. Can you recommend any issue which I could help you with? It would be my first open source PR.
Someone here to answer a question about the project?
Hi. I have an enhancement for issue 482, but don't have permission to push to a feature branch. Could I please have access so I can issue a PR? Thanks. (shouldly/shouldly#482)
Hi @puzuwe . You're welcome to jump in and help. You can pick one of the GitHub issues that are marked "Up for grabs". The one also marked "First Timer" is particularly suitable for first timers :) https://github.com/shouldly/shouldly/issues?q=is%3Aissue+is%3Aopen+label%3A%22Up+For+Grabs%22
I recently submitted a PR to shouldly that adds a getting started guide to the docs, but the CI tests failed, can someone help me with that please?
I only changed the docs, so it seems strange to me that the tests failed, btw it's my first PR, so I don't know a lot about all of that stuff.
My PR build is failing with the following message -
https://ci.appveyor.com/project/shouldly/shouldly/builds/31356789/job/ffwql97doclcaiou
Can anyone help with the issue?
@hrai I happen to know from other OSS projects what that is. You can link to shouldly/shouldly#605 from your PR with a note that the problem is in the master branch, not in your PR.
Hiya, just a heads up, i did 2 unrelated PR's and the merge failed twice on appveyor, seems to be around outdated Microsoft.SourceLink.GitHub ie. https://github.com/shouldly/shouldly/pull/606/commits/ea53c6492299723276391596e2d0c0376176ce90 so i included that in both PR's just to go green.
This is an open source project and I know people contribute on their free time which is hard to get these days. I was wondering if the maintainer has considered pulling in long term contributors to help out with the PR merges. This would enable faster resolution of issues.
hi all, anyone experience where Shouldly suddenly doesnt know how to find a diff tool. It's been working perfectly fine in visual studio, then suddenly stops working for no visible reason? the tests still work, as in they verify or fail, just doesnt launch the default visual studio diff tool anymore.
1 reply
