Hi,

It seems like the HTTP Assert package does not allow me to specify a body to pass in a POST request for example. Looking at the HTTPBody() function, the body argument is set to nil:
req, err := http.NewRequest(method, url+"?"+values.Encode(), nil)

Is this by design, or am I looking at a missing feature?

Cheers,

General summary of the issue

Hard to explain, but it took us a complete breakdown of a very complicated script to see what was happening. Please see the test code below.

Describe your environment

Pester version : 5.1.1 C:\Program Files\WindowsPowerShell\Modules\Pester\5.1.1\Pester.psm1
PowerShell version : 5.1.14393.3866
OS version : Microsoft Windows NT 10.0.14393.0

Summary

When some Throwable-related assertion fails the actual Throwable that failed the check is not described beyond what actually caused assertion failure (e.g. message mismatch). In non trivial code when unexpected Exceptions are thrown this makes debugging inconvenient.

Dumping more comprehensive (class, message, stack, perhaps even recursive info about causes) info about the a

Feature Request

Description:
API for Date matchers. Some matchers are inspired by Jasmine Matchers.

Possible solution:

Jasmine-like matchers:

expect(date).toBeDate(); // Matcher added
expect(date).toBeValidDate();  // Matcher added

expect(date).toBeAfter(otherDate); // Matcher added
expect(date).toBeBefore(otherDa

Location of the documentation

https://pandera.readthedocs.io/en/stable/checks.html

Documentation problem

An important piece of functionality is that ignore_na=True in a Check will drop elements with nulls (for columns) and rows with any nulls (for dataframe checks)

Suggested fix for documentation

Add documentation for this in the user guide so that it's highlighted

As a SDET
I want a documentation or Wiki page where the expected vs actual field matching is explained
So that I can use these in my test automation to test the server response payloads and headers
e.g. id=123 , id="123", isValid=true, isValid="true" etc

AC1:

Cover the following currently supported mechanisms with examples

• $EQ
• (int)
• (float) or (decimal)
• (boolean)

Platform (all, jvm, js, android): all
Extension (none, kotlin 1.3): none

Code related feature

We also want to provide samples for the infix api

Following the things you need to do:

• copy CollectionAssertionsSample from fluent-api, adjust imports ...api.fluent... to ...api.infix... and ajdust the samples accordingly (always use the infix syntax, never the fluent).
• ch

Normally, the "to be truthy" assertion does not take any value as it simply asserts that a subject can be coerced to a boolean true (in the case of "to be falsy" it is coercion to boolean false).

It seems that early on these assertions inherited an optional form where a custom message can be supplied as their argument - this was likely inspired by earlier assertions frameworks (assert on node