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,

I took me some debugging to find out why my property tests with Koin fail.
I expected KoinListener would reset Koin after each test, no matter if it's a basic test or a property test.

Then I found out that the second run of my simple test reuses the values saved in Koin from the first run.

checkAll<Boolean> { arg -> // true/false
  declareMock {
      Repository(arg)
  }
  get<Ser

Before you file a bug, have you:

• Tried upgrading to newest version of Fluent Assertions, to see if your issue has already been resolved and released?
• Checked existing open and closed issues, to see if the issue has already been reported?
• Tried reproducing your problem in a new isolated proje

Summary

AssertJ error messages currently do not take into account that toString of asserted values may contain new lines.

The resulting error messages can at times look awkward due to missing indentation.

Example

For example let's consider a class where toString returns multi-line XML:

<xml>
  <value>A</value>
</xml>

For simplicity I will use the fo

Let's dive into the source code:

https://github.com/sindresorhus/is/blob/d528545e02de3396ea900cd93af478292f0697ee/source/index.ts#L184

Only [Symbol.iterator] property is checked, meaning the value is at least Iterable<T>. It may be IterableIterator<T> if the presence of one more property, next, is ensured.

interface Iterable<T> {
    [Symbol.iterator](): Iterator<T>;
}

Describe the bug
pa.errors.SchemaErrors.failure_cases only returns the first 10 failure_cases

• I have checked that this issue has not already been reported.
• I have confirmed this bug exists on the latest version of pandera. 0.6.5
• (optional) I have confirmed this bug exists on the master branch of pandera.

Note: Please read [this guide](https://matthewrocklin.c

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): jvm
Extension (none, kotlin 1.3): none

Code related feature
expect(path).notToBeExecutable()

//instead of

expect(path).feature { f(it::isExecutable) }.toEqual(false)
Following the things you need to do:

logic

extend PathAssertions with a function isNotExecutable (see PathAssertions as a guideline)
implement isNotReadable in DefaultPathAssertions.kt by

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