public static ExpectedCondition<List<WebElement>> texts(final By locator, final String... expectedTexts) {
...
                if (actualTexts.size() != expectedTexts.length) {
                    return null;
                }
                for (int i = 0; i < actualTexts.size(); i++) {
                    if (!actualTexts.get(i).contains(expectedTexts[i])) {
                        return null;
/*
    тут - сверяем количество, порядок и тексты = на вхождение
*/
public static ExpectedCondition<List<WebElement>> visibleTextsOf(final By locator, final String... expectedTexts) {
...
                if (!actualTexts.equals(Arrays.asList(expectedTexts))) {
/*
    а тут - проверям количество, порядок и тексты = на равенство

    красивая реализация)

    только вот имена кондишенов - будут путать)

    было бы ок
    тексты проверяем на вхождение
        textsOf
        textsOfVisible
    тексты проверяем на равенство
        exactTextsOf
        exactTextsOfVisible (ты как раз такой вариант и реализовал)
    предлагаю textsOf - так и оставить (textsOf - Of для единообразия добавь)
    и реализовать пару для exactTextsOf и exactTextsOfVisible
    ведь именно они нужны для todoMVC

    textsOf - оставь
    далее пригодится
    а вот textsOfVisible - уже и не реализовывай
    раз пока потребности нету

    можно даже было бы ограничиться  вариантом - реализовать только exactTextsOfVisible
    (это к вопросу - сколько вариантов ассертов нам нужно для этого приложения)

*/
public static void assertTasksAre(String... tasksTexts) {
public static void assertVisibleTasks(String... taskTexts) {
public static void assertNoTasks() {
public static void assertNoVisibleTasks() {
/*
    это про то, как смочь ограничиться
    мы это уже рассматривали
    на всякий случай повторю

    https://drive.google.com/file/d/0B8hgIBw8-V-AdGxxU1R3enl1RzQ/view?ts=567ab8d7

    мы можем быть максимально точными и держать 4 проверки
        2 -
            в списке = такси с такими-то текстами
            в списке = пусто
        и еще 2 -
            в отфильтрованном по visible списке = таски с такими-то текстами
            в отфильтрованном по visible списке = пусто
        И за точность будем платить  тем - что надо думать - когда какую проверку вызвать правильнее
        и если это делать бездумно - то при небольших изменениях сценариев - могут тесты падать на проверках,
        или второй вариант - не будем нормально пользоваться полученной точностью...

        мы можем исходить из того, что ошибку, когда невидимые таски копятся в списке - мы тестим на более низком уровне,
        и на UI уровне - нам не нужно до этого уточняться. Поэтому - мы будем держать всего 2 проверки
              в отфильтрованном по visible списке = таски с такими-то текстами
              в отфильтрованном по visible списке = пусто
        В таком случае - каждый раз понятно - какую проверку вызывать - получаем более KISS картину
        правда, платим за это точностью) Но - возможно - если мы уже отдельно это в тестах покрыли -
        что у нас не копятся невидимые таски - так мы и не платим ) И - тогда - все проще в написании тестов,
        и в их сопровождении.
        Тогда - поскольку обе проверки реализованы одинаково и других нету - можно из имен проверок скрыть этот нюанс
        и назвать их assertTasks и assertNoTasks (хотя в них работаем с отфильтрованным по visible списком тасок)


    если ограничиться двумя проверками
    то тебе будет достаточно кондишенов exactTextsOfVisible и sizeOfVisible

    на самом деле - дореализовать и exactTextsOf - уже дело техники
    все сложности - позади)
    все разобрано уже

    так что - как считаешь нужным делай

    по сути - выбор такой
        сэкономить на реализации разных кондишенов
        и получить 2 метода для проверок

        дореализовать и exactTextsOf
        и как и ранее - оперировать 4 проверками
*/