llorllale / cactoos-matchers Goto Github PK

We need to add more information/docs about project functionality to the main page.

Now the main page didn't provide any examples what exactly matchers we have and how they can be useful.

Hi @llorllale ,
When do we planning to release the latest features (v0.12)?

The puzzle 58-b44e1a44 from #58 has to be resolved:

The puzzle was created by @rultor on 03-Jan-19.

If you have any technical questions, don't ask me, submit new tickets instead. The task will be "done" when the problem is fixed and the text of the puzzle is removed from the source code. Here is more about PDD and about me.

Now, when you want to check that text has specific lines you have to use something like

    @Test
    public void hasLines() {
        MatcherAssert.assertThat(
            new TextOf(....).asString(),
            Matchers.anyOf(
                // OSX, Linux
                Matchers.equalTo(
                    "Line A.\n\n" +
                        "Line B.\n" +

                        "Line N.\n\n]."
                ),
                // Windows
                Matchers.equalTo(
                    "Line A.\r\n\r\n" +
                        "Line B.\r\n" +
                          
                        "Line N.\r\n\r\n"
                )
            )
        );
    }

with text duplication which cause long tests.

TextIs.PREFIX String is wrong: it is "Text with " but should be "Text is ".

The puzzle 7-0cc4122b from #7 has to be resolved:

The puzzle was created by Victor Noël on 19-May-18.

Estimate: 30 minutes,

If you have any technical questions, don't ask me, submit new tickets instead. The task will be "done" when the problem is fixed and the text of the puzzle is removed from the source code. Here is more about PDD and about me.

FuncApplies.describeTo refers to Scalar instead of Func

For example,

        MatcherAssert.assertThat(
            new ListOf<>("aA", "bB", "cC"),
            new HasValues<>("aA", "cC")
        );

        MatcherAssert.assertThat(
            new ListOf<>("aA", "bB", "cC"),
            new HasValues<>(
                expected -> expected.endsWith("A") || expected.endsWith("cC") 
            )
        );

        MatcherAssert.assertThat(
            new ListOf<>("aA", "bB", "cC"),
            new HasValues<>(
                expected -> expected.startsWith("a") || expected.startsWith("b")
            )
        );

Let's release 0.9 in order to fix yegor256/cactoos#751. We're not releasing a 1.0 yet because #1 is yet to be fixed.

The puzzle 18-b493cd89 from #18 has to be resolved:

The puzzle was created by George Aristy on 08-Dec-18.

If you have any technical questions, don't ask me, submit new tickets instead. The task will be "done" when the problem is fixed and the text of the puzzle is removed from the source code. Here is more about PDD and about me.

The puzzle 16-acf734f9 from #16 has to be resolved:

The puzzle was created by Yurii Dubinka on 08-Dec-18.

If you have any technical questions, don't ask me, submit new tickets instead. The task will be "done" when the problem is fixed and the text of the puzzle is removed from the source code. Here is more about PDD and about me.

This ticket is moved from yegor256/cactoos#816

Currently, ScalarHasValue doesn't override method describeMismatchSafely that leads to the next problem:

final ScalarHasValue<String> matcher =
    new ScalarHasValue<>(new IsEqual<>("expected"));
final Scalar<String> scalar = new UncheckedScalar<>(() -> "actual");
final StringDescription description = new StringDescription();
matcher.describeMismatch(scalar, description);
System.out.println(description.toString());
// the out is:
// was <org.cactoos.scalar.UncheckedScalar@368239c8>
// how it should look like:
// was "actual"

so it prints an actual version incorrectly: default toString method is called for the Scalar.

Expected:

• the value of scalar is printed as an actual value of matching.

What should be fixed

• class ScalarHasValue has to override method describeMismatchSafely and convert Scalar to String properly.

Now hamcrest has 2 different matchers in order to check the size of the collection (which is iterable) and iterable. Sometimes you can't use them easily without static methods from org.hamcrest.Matchers:

• org.hamcrest.Matchers#iterableWithSize(...)
• org.hamcrest.Matchers#hasSize(...)

We are going to deprecate the static methods from Matchers thus we need to give an alternative to that behavior.

The puzzle 35-b5eec46c from #35 has to be resolved:

The puzzle was created by Yurii Dubinka on 09-Dec-18.

If you have any technical questions, don't ask me, submit new tickets instead. The task will be "done" when the problem is fixed and the text of the puzzle is removed from the source code. Here is more about PDD and about me.

There are a lot of changes happens to project since the last release in December.
I would like to use them in my projects.

The puzzle 32-59ea1519 from #32 has to be resolved:

The puzzle was created by rultor on 27-Nov-18.

If you have any technical questions, don't ask me, submit new tickets instead. The task will be "done" when the problem is fixed and the text of the puzzle is removed from the source code. Here is more about PDD and about me.

Let's update Copyright notice to 2019.

The puzzle 58-21ae45f3 from #58 has to be resolved:

The puzzle was created by @rultor on 03-Jan-19.

If you have any technical questions, don't ask me, submit new tickets instead. The task will be "done" when the problem is fixed and the text of the puzzle is removed from the source code. Here is more about PDD and about me.

In order to make the project more clear for understanding i propose to move the matchers to dedicated packages like:

• org.llorllale.cactoos.matcher.text
• org.llorllale.cactoos.matcher.collection
• org.llorllale.cactoos.matcher.iterable
• org.llorllale.cactoos.matcher.number
• org.llorllale.cactoos.matcher.io
• org.llorllale.cactoos.matcher.scalar
• org.llorllale.cactoos.matcher.text
• org.llorllale.cactoos.matcher.exception
• etc

For now the version is 0.11, however, there are several files with incorrect versions like 1.1, 1.0, 0.29.

TextHasString default is behaving incorrectly, according to its name. I've received the following error when implementing a test class:

java.lang.AssertionError: 
Expected: Text with "text/plain"
     but: Text with "HTTP/1.1 200 OK\r\nContent-type: text/plain"

According to the class name, it's expected that this matcher asserts if there is any occurrence of the sample String in the text object; however it is expecting the exact match of the sample String and the text.

I see two solutions for this case:

• Refactor TextHasString and change its default behavior, which uses IsEqual<> for comparing, when it should use StringContains;
• Rename the class to something like TextIsString or TextEqualsString (but I don't know if it is worth just renaming; why don't just use IsEqual<> instead then?).

Now, if we want to use the org.hamcrest.core.AllOf we have to write something like

new AllOf<>(
    new IterableOf<>(
        new Matcher<>(
            ...
        ),
        new Matcher<>(
            ...
        ),
        new Matcher<>(
            ...
        )
    )
)

We can avoid it using Matchers.allOf(Matcher ...args), but its belongs to the lib hamcrest-all.
I propose to extend the AllOf in order to support the vararg ctor which allows us to avoid instantiation of iterable, and without unnecessary indents, we may write most matchers like:

new AllOf<>(
    new Matcher<>( ... ),
    new Matcher<>( ... ),
    new Matcher<>( ... )
)

We missed these matchers found only in cactoos test packages. We need to bring them over here:

• BehavesAsCollection
• BehavesAsList
• BehavesAsMap
• ClearDeletesAllValues
• PutUpdatesValues
• PutAllUpdatesValues
• RemoveDeletesValues

We'll release 1.0 once this is complete.

Today I found that HasLines

    @Test
    public void test(){
        MatcherAssert.assertThat(
            String.format("l1%nl2"),
            new HasLines("l1", "l3")
        );
    }

doesn't explain the failed scenario properly

java.lang.AssertionError: 
Expected: <org.cactoos.text.TextOf@3ab39c39>
     but: <org.cactoos.text.TextOf@2eee9593>
	at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)

We need to call text.asString() instead of Text.toString().

ScalarHasValue has the following Ctor:

The javadoc speaks about text which is wrong. And so does the param in the first Ctor.
The scalar is generic and text is not an appropriate name.

I would suggest a more generic name like value.

Need to un-comment the jacoco configurations in the POM and make the following errors go away:

--- jacoco-maven-plugin:0.7.7.201606060606:check (jacoco-check) @ cactoos-matchers ---
Loading execution data file C:\dev\cactoos-matchers\target\jacoco.exec
Analyzed bundle 'cactoos-matchers' with 7 classes
Rule violated for bundle cactoos-matchers: instructions covered ratio is 0.00, but expected minimum is 0.61
Rule violated for bundle cactoos-matchers: lines covered ratio is 0.00, but expected minimum is 0.65
Rule violated for bundle cactoos-matchers: branches covered ratio is 0.00, but expected minimum is 0.65
Rule violated for bundle cactoos-matchers: complexity covered ratio is 0.00, but expected minimum is 0.57
Rule violated for bundle cactoos-matchers: methods covered ratio is 0.00, but expected minimum is 0.57

For starters, the CodeCov report from cactoos can be found here.

Let's create TextStartsWith and TextEndsWith as an OO laternative to Matchers.startsWit/Matchers.endsWith

On Fedora26, Oracle JDK8 u171 x64.

Looks like RunsInThreadTest assumes that concurrent modification of a HashMap only generates ConcurrentModificationException but actually one must not assume any particular exception type when there is more than one thread accessing the HashMap.

Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.536 sec <<< FAILURE! - in org.llorllale.cactoos.matchers.RunsInThreadsTest
matchNegative(org.llorllale.cactoos.matchers.RunsInThreadsTest)  Time elapsed: 0.21 sec  <<< ERROR!
java.io.UncheckedIOException: java.io.IOException: java.util.concurrent.ExecutionException: java.lang.ClassCastException: java.util.HashMap$Node cannot be cast to java.util.HashMap$TreeNode
        at org.cactoos.scalar.UncheckedScalar.value(UncheckedScalar.java:60)
        at org.llorllale.cactoos.matchers.RunsInThreads.matchesSafely(RunsInThreads.java:109)
        at org.llorllale.cactoos.matchers.RunsInThreadsTest.matchNegative(RunsInThreadsTest.java:65)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
        at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
        at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
        at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
        at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
        at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
        at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
        at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
        at org.apache.maven.surefire.junitcore.pc.Scheduler$1.run(Scheduler.java:393)
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
        at java.util.concurrent.FutureTask.run(FutureTask.java:266)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at java.lang.Thread.run(Thread.java:748)
Caused by: java.io.IOException: java.util.concurrent.ExecutionException: java.lang.ClassCastException: java.util.HashMap$Node cannot be cast to java.util.HashMap$TreeNode
        at org.cactoos.func.UncheckedFunc.lambda$apply$0(UncheckedFunc.java:58)
        at org.cactoos.scalar.CheckedScalar.value(CheckedScalar.java:84)
        at org.cactoos.scalar.IoCheckedScalar.value(IoCheckedScalar.java:65)
        at org.cactoos.scalar.UncheckedScalar.value(UncheckedScalar.java:58)
        at org.cactoos.func.UncheckedFunc.apply(UncheckedFunc.java:59)
        at org.cactoos.scalar.CheckedScalar.wrappedException(CheckedScalar.java:108)
        at org.cactoos.scalar.CheckedScalar.value(CheckedScalar.java:93)
        at org.cactoos.scalar.IoCheckedScalar.value(IoCheckedScalar.java:65)
        at org.cactoos.scalar.UncheckedScalar.value(UncheckedScalar.java:58)
        ... 20 more
Caused by: java.util.concurrent.ExecutionException: java.lang.ClassCastException: java.util.HashMap$Node cannot be cast to java.util.HashMap$TreeNode
        at java.util.concurrent.FutureTask.report(FutureTask.java:122)
        at java.util.concurrent.FutureTask.get(FutureTask.java:192)
        at org.cactoos.scalar.And.lambda$null$0(And.java:111)
        at org.cactoos.scalar.And.value(And.java:137)
        at org.cactoos.scalar.And.value(And.java:61)
        at org.cactoos.scalar.CheckedScalar.value(CheckedScalar.java:84)
        ... 22 more
Caused by: java.lang.ClassCastException: java.util.HashMap$Node cannot be cast to java.util.HashMap$TreeNode
        at java.util.HashMap$TreeNode.moveRootToFront(HashMap.java:1832)
        at java.util.HashMap$TreeNode.putTreeVal(HashMap.java:2012)
        at java.util.HashMap.putVal(HashMap.java:638)
        at java.util.HashMap.put(HashMap.java:612)
        at org.llorllale.cactoos.matchers.RunsInThreadsTest.modify(RunsInThreadsTest.java:88)
        at org.llorllale.cactoos.matchers.RunsInThreads.lambda$matchesSafely$0(RunsInThreads.java:98)
        ... 4 more

The puzzle 36-7ebfe74b from #36 has to be resolved:

The puzzle was created by Yurii Dubinka on 04-Dec-18.

If you have any technical questions, don't ask me, submit new tickets instead. The task will be "done" when the problem is fixed and the text of the puzzle is removed from the source code. Here is more about PDD and about me.

In case of single property

      MatcherAssert.assertThat(
            "The 1st team has expected <team/1st/properties/1st> tag",
            new PropertiesOf<>(...),
            new HasProperties("the key", "the value")
      );

In case of multiple property it may looks like

      MatcherAssert.assertThat(
            "The 1st team has expected <team/1st/properties/1st> tag",
            new PropertiesOf<>(...),
            new HasProperties(MapEntry ...entries)
      );

Let's discuss the possiblity of this functionality.

TypeSafeMatcher was chosen as an example of how to easily implement hamcrest matcher, however, we have code duplication for each implementation of TypeSafeMatcher:

• overriding of 3 methods match, describeTo, describeMismatch
• for each of these methods, we need the fields in order to constructs the methods
• most of these methods are operating with cactoos primitives, thus, we are using a lot of Unchecked implementations
• when we were working on Text-based matchers we understood that something went wrong and implement the TextMatcherEnvelope. That was a good decision, but we need to extend it to the whole project. TextMatcherEnvelope should extend Envelope
• envelope give a standard approach for matcher implementation, for example, the InputHasContent has no overridden describeMismatch method and this won't happen in case if the envelope was used. It similar to Assertion vsMatcherAssert.assertThat, when developers skipping the reason explanation of test (they can't do that using Assertion).

The envelope may look like

package org.llorllale.cactoos.matchers;

import org.cactoos.BiProc;
import org.cactoos.Func;
import org.cactoos.Proc;
import org.cactoos.func.UncheckedBiProc;
import org.cactoos.func.UncheckedFunc;
import org.cactoos.func.UncheckedProc;
import org.hamcrest.Description;
import org.hamcrest.Matcher;
import org.hamcrest.TypeSafeMatcher;

public class Envelope<T> extends TypeSafeMatcher<T> {

    private final Matcher<T> origin;

    public Envelope(
        final Func<T, Boolean> matches,
        final Proc<Description> describe,
        final BiProc<Description, T> mismatch
    ) {
        this(new TypeSafeMatcher<T>() {
                 @Override
                 public void describeTo(final Description description) {
                     new UncheckedProc<>(describe).exec(description);
                 }

                 @Override
                 protected boolean matchesSafely(final T o) {
                     return new UncheckedFunc<>(matches).apply(o);
                 }

                 @Override
                 protected final void describeMismatchSafely(
                     final T item, final Description desc) {
                    new UncheckedBiProc<>(mismatch).exec(desc, item);
                 }
             }
        );
    }

    public Envelope(final Matcher<T> origin) {
        this.origin = origin;
    }

    @Override
    protected final boolean matchesSafely(final T t) {
        return this.origin.matches(t);
    }

    @Override
    public final void describeTo(final Description desc) {
        this.origin.describeTo(desc);
    }

    @Override
    protected final void describeMismatchSafely(
        final T item, final Description desc) {
        this.origin.describeMismatch(item, desc);
    }
}

For example, the InputHasContent with envelope will became

public final class InputHasContent extends Envelope<Input> {

    /**
     * Ctor.
     * @param text The text to match against
     */
    public InputHasContent(final String text) {
        this(new TextOf(text));
    }

    /**
     * Ctor.
     * @param text The text to match against
     */
    public InputHasContent(final Text text) {
        this(new MatcherOf<>((String input) -> text.asString().equals(input)));
    }

    /**
     * Ctor.
     * @param mtr Matcher of the text
     */
    public InputHasContent(final Matcher<String> mtr) {
        super(
            input -> mtr.matches(new TextOf(input).asString()),
            desc -> {
                desc.appendText("Input with ").appendDescriptionOf(mtr);
            },
            (desc, input) -> desc.appendText("Input with ").appendValue(
                new TextOf(input).asString()
            )
        );
    }
}

which is much shorter than

public final class InputHasContent extends TypeSafeMatcher<Input> {

    /**
     * Matcher of the value.
     */
    private final Matcher<String> matcher;

    /**
     * Ctor.
     * @param text The text to match against
     */
    public InputHasContent(final String text) {
        this(new TextOf(text));
    }

    /**
     * Ctor.
     * @param text The text to match against
     */
    public InputHasContent(final Text text) {
        this(new MatcherOf<>((String input) -> text.asString().equals(input)));
    }

    /**
     * Ctor.
     * @param mtr Matcher of the text
     */
    public InputHasContent(final Matcher<String> mtr) {
        super();
        this.matcher = mtr;
    }

    @Override
    public boolean matchesSafely(final Input item) {
        return this.matcher.matches(
            new UncheckedText(
                new TextOf(item)
            ).asString()
        );
    }

    @Override
    public void describeTo(final Description description) {
        description.appendText("Input with ");
        description.appendDescriptionOf(this.matcher);
    }
}

Log

Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.168 sec <<< FAILURE! - in org.llorllale.cactoos.matchers.RunsInThreadsTest
matchNegative(org.llorllale.cactoos.matchers.RunsInThreadsTest)  Time elapsed: 0.167 sec  <<< FAILURE!
java.lang.AssertionError: 
Can concurrently modify HashMap
Expected: <false>
     but: was <true>
	at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
	at org.llorllale.cactoos.matchers.RunsInThreadsTest.matchNegative(RunsInThreadsTest.java:61)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
	at org.apache.maven.surefire.junitcore.pc.Scheduler$1.run(Scheduler.java:393)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at java.lang.Thread.run(Thread.java:748)

Use of this specific overload of MatcherAssert.assertThat() should fail the build because providing an adequate assertion message helps a) understand the test better, and b) helps determining why a build failed (if a test fails).

Otherwise cactoos build will fail due to an "undeclared dependency not being used"

The tests in cactoos-matchers are in the package org.cactoos.matchers and do not refer to the classes in org.llorllale.cactoos.matchers, so they are effectively testing the matchers from cactoos (which is an old version, see #11).

The tests should be ported to the new matchers.

The puzzle 18-a9679abd from #18 has to be resolved:

The puzzle was created by George Aristy on 08-Dec-18.

If you have any technical questions, don't ask me, submit new tickets instead. The task will be "done" when the problem is fixed and the text of the puzzle is removed from the source code. Here is more about PDD and about me.

Now when i need to write the unit test with java.util.Map i have to use something like

        MatcherAssert.assertThat(
            "The 1st team has expected <team/1st/properties/1st> tag",
            new MapOf<>(...),
            new IsMapContaining<>(
                new IsEqual<>("the key"),
                new IsEqual<>("the value")
            )
        );

and it would be more clear if we add a new matcher HasEntry like

       MatcherAssert.assertThat(
            "The 1st team has expected <team/1st/properties/1st> tag",
            new MapOf<>(...),
            new HasEntry<>("the key", "the value")
        );

The class may have 3 constructors:

• HasEntry(key, value)
• HasEntry(Map.Entry entry)
• HasEntry(BiFunc<K,V,Boolean, String mismatch explanation))

Let's discuss the possiblity of this feature.

Shamelessly copied from yegor256/cactoos-http#49 :)

New qulice version brings following important changes:

• removal of @author tag (it is prohibited now)
• removal of @version tag (it is prohibited now)
• license header should start with /* instead of /** - this will fix problem with IntelliJ reporting it as a javadoc that is not attached to any class
• checkstyle validation performance improvement (speedup of ~ 10%)
• And few minor formatting changes.

Please upgrade the qulice and fix the new problems found.

There is two thing really strange:

1. cactoos-matchers relies on an old version of cactoos that currently contains the very same matchers
2. if cactoos-matchers were relying on a newer version of cactoos, the latter would rely on cactoos-matchers: this is not very good architecturally speaking!

This should be fixed, I don't know how.

We should enable findbugs in qulice, there is no work to do, the build already passes with it currently.

Also there is a useless configuration property in qulice configuration too that could be removed.

During the implementation of yegor256/cactoos#968 I've started to think how to avoid the cases like #22.
Sometimes the test from #22 is failing, sometimes not and in order to prevent it again we can execute the fragile concurrent test(s) at least 20-50 times which can give us some level of confidence.

For example, junit 5 support such way

@RepeatedTest(10)
void repeatedTest() {
    // ...
}

As i understood we are not considering the upgrade to junit5 now, so i've googled a few approaches which may help (but review is required):

• https://turreta.com/2017/07/15/junit-4-run-test-method-more-than-once/
• https://stackoverflow.com/questions/1492856/easy-way-of-running-the-same-junit-test-over-and-over

The puzzle 32-2540e9c8 from #32 has to be resolved:

The puzzle was created by rultor on 27-Nov-18.

If you have any technical questions, don't ask me, submit new tickets instead. The task will be "done" when the problem is fixed and the text of the puzzle is removed from the source code. Here is more about PDD and about me.

Let's add a substitute for MatcherAssert.assertThat, something like Assertion<T>:

new Assertion<>(
    "Collection cannot be empty",
    collection.size(),
    new IsNot<>(0)
).verify();    //might throw AssertionError

Note: ctor must have the reason text parameter

The available Matchers often takes Strings in their constructor.
They should also support taking Text.

This concerns at least:

• InputHasContent
• TextHasString

The puzzle 52-f2eb48e2 from #52 has to be resolved:

The puzzle was created by @dgroup on 15-Jan-19.

If you have any technical questions, don't ask me, submit new tickets instead. The task will be "done" when the problem is fixed and the text of the puzzle is removed from the source code. Here is more about PDD and about me.

Observed in #48
https://travis-ci.org/llorllale/cactoos-matchers/builds/465352255?utm_source=github_status&utm_medium=notification

Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.247 sec <<< FAILURE! - in org.llorllale.cactoos.matchers.RunsInThreadsTest
matchNegative(org.llorllale.cactoos.matchers.RunsInThreadsTest)  Time elapsed: 0.207 sec  <<< FAILURE!
java.lang.AssertionError: 
Can concurrently modify HashMap
Expected: <false>
     but: was <true>
	at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
	at org.llorllale.cactoos.matchers.RunsInThreadsTest.matchNegative(RunsInThreadsTest.java:61)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
	at org.apache.maven.surefire.junitcore.pc.Scheduler$1.run(Scheduler.java:393)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at java.lang.Thread.run(Thread.java:748)

Let's create new matcher IsTrue<Boolean>.