Александр

coverage говорит о покрытии тестами конкретных строк. Если во время прогона тестов не были затронуты какие-то строки исходного кода, то coverage будет менее 100%. В среднем считается что хорошее покрытие это > 80%. 100% достичь слишком трудно и дорого (и не нужно).

> И если я напишу еще 1000 такого типа тестов это лишь будет гарантировать, что всё хорошо на этих 1000 наборах данных, а вдруг ошибка как раз в другом, 1001-м наборе?

Гарантий вам никто не даст. Для гарантий есть формальная верификация, но это больше про математику чем про программирование. А так это ответственность программиста тестировать пограничные случаи. Ничего страшного в том что вы их пропустили обычно не приосходит. Просто если возникнет баг, то сначала добавите тест который его воспроизведет, а затем уже почините.

Из интересного:

* property-based testing https://en.wikipedia.org/wiki/QuickCheck
* bdd behat.org/en/latest/guides.html
* browser tests https://codeception.com/
* как писать тесты (концептуальная история) https://ru.hexlet.io/blog/posts/how-to-test-code

Пробовали array_count_values() ?

Qt работает только с OpenSSL 1.0.x версией, 1.1.х еще не поддерживается

Начиная с емнип 5.6 работа с объектной моделью данных не уступает в скорости процедурному коду, а в потреблении памяти сильно выигрывает, за счет создания только тех объектов, которые необходимы в данный момент в коде, а не тянутся все 100500 функций из процедурной лапши.

Допустим, ваши данные хранятся в MySQL в таблице questions. Чтобы в PHP получить все данные с сортировкой значений поля status в определённом вами порядке сделайте так:

App\Question::orderByRaw("FIELD(status,'Без ответа,'Скрыт')")->get();

придётся перечислить все возможные статусы 'Без ответа,'Скрыт' и так далее - иначе фокус не удастся.

$model = Model::first() ?? Model::forceCreate(...);

api.jquery.com/prepend

вы делаете ту же ошибку, что и в предыдущих вопросах по парсингу: работаете с уже интерпретированными данными вместо сырых.
когда вы в файле пишите $metro = 'Ìåòðî Ïëàíåðíàÿ 474 ì'; строка приобретает кодировку этого файла, а не исходную, соответственно, любые камлания по конвертации лишены всякого смысла.

Создадим коллекцию эллементов с именами:

$collection = collect([['name' => 'c'], ['name' => 'b'], ['name' => 'a']]);

Дампним и посмотрим что у нас там:

Collection {#581 ▼
  #items: array:3 [▼
    0 => array:1 [▼
      "name" => "c"
    ]
    1 => array:1 [▼
      "name" => "b"
    ]
    2 => array:1 [▼
      "name" => "a"
    ]
  ]
}

А теперь отсортируем и дампним снова dd($collection->sortBy('name'));:

Collection {#566 ▼
  #items: array:3 [▼
    2 => array:1 [▼
      "name" => "a"
    ]
    1 => array:1 [▼
      "name" => "b"
    ]
    0 => array:1 [▼
      "name" => "c"
    ]
  ]
}

Как видите порядок в коллекции изменился, теперь она отсортирована по имени. Но, ключи сохранились прежние, поэтому вызов dd($data[0],$data[1],$data[2]); выведет значения в старом порядке.

То есть сортировка будет сохранена при порядковом обходе коллекции, обращаясь по ключу вы нарушаете этот порядок.

Метод values() вернет новую коллекцию, в которой ключи сбросятся и будут пронумерованы заново, по порядку, то есть ключи будут соответствовать сортировке
$collection->values()

Если вы получаете коллекцию из БД, то эффективнее делать сортировку непосредственно на стороне БД, в остальных случаях учитывайте описанное поведение коллекций.

$now = \Carbon\Carbon::now();
$now->minute($now->minute - $now->minute % 15)->second(0)

class AlbumTest extends TestCase
{
    use DatabaseMigrations;

    public function test()
    {
        $album = factory('Album')->create();

        $songs = new Collection([
            factory('Song')->make(['duration' => 291]),
            factory('Song')->make(['duration' => 123]),
            factory('Song')->make(['duration' => 100]),
        ]);

        $album->songs()->saveMany($songs);
    }
}

Потому что его нет в fillable?

Не говоря уж про то что отправляется departamen_id, а во всех других местах departament_id

void* используется как указатель на сырые байтовые данные, не имеющие конкретного типа.
Обычно это используется…
1. В чтении-записи в файлы и на устройства, когда мы можем писать туда абсолютно любые типы.
2. В «многоликих» функциях, которые могут принимать данные разных типов (malloc/calloc, часть функций WinAPI и ODBC).
3. Как дескриптор — указатель, который запрещается разыменовывать. В Си для этого также часто используют указатель на недоопределённый тип, в Паскале с другими правилами эквивалентности типов — на пустой record. Но только пока не появится очередная многоликая функция вроде CloseHandle.
4. Для обеспечения т.н. замыкания — передачи callback’у контекста, откуда была вызвана функция, вызвавшая callback.

BOOL WINAPI EnumWindows(
  _In_ WNDENUMPROC lpEnumFunc,
  _In_ LPARAM      lParam
);

BOOL CALLBACK EnumWindowsProc(
  _In_ HWND   hwnd,
  _In_ LPARAM lParam
);

Вот этот LPARAM, который обычно определяется как какой-то указатель, и есть замыкание. Функция EnumWindows обещает передать его в функцию lpEnumFunc без изменений.
(В Си++ для этого также используют виртуальные интерфейсы, но такой метод, сами понимаете, языкозависим и не годится для межъязыкового API.)

Что происходит на стороне функции? Одно из двух (считаем, функция написана на ЯВУ).
1. Либо вызывается некая функция устройства, которая говорит: «записать 100 байт», и дальше уже работает железо.
2. Либо мы преобразуем void* в нужный нам тип и работаем с ним.

Типы указателям дают по трём причинам.
1. Вы забыли про операцию «разыменовать указатель». Чтобы его разыменовать, он должен иметь тип!
2. Чтобы не ошибаться и не переприсвоить несовместимые указатели.
3. Для полиморфизма — в Си++, давая delete x, мы даже можем не хранить, сколько байтов в блоке, поскольку мы знаем длину типа. (Есть ещё и виртуальные классы, но это другой вопрос.)