Ипатьев

Выносить имя таблицы и колонки в переменные не нужно. Их надо написать прямо в запросе.
А дату надо подставлять в запрос через подготовленные выражения.

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

$sql = "SELECT * FROM название таблицы WHERE  DATE = ?";
$result = $conn->execute_query($sql, [$dateNew]);
$usersArray = $result->fetch_all(MYSQLI_ASSOC);

Если же хранится дата и время, то надо подставить начальный и конечный период. То есть запрос будет

SELECT * FROM название таблицы WHERE  DATE BETWEEN ? AND ?

и в него подставлять значения "$dateNew 00:00:00" и "$dateNew 23:23:59"

Чтобы получить одну запись, надо добавить в запрос оператор LIMIT 1, а fetch_all(MYSQLI_ASSOC) поменять на fetch_assoc()
Чтобы получить "последнюю" запись, надо добавить в запрос сортировку по тому полю, по которому считается последовательность добавления. И сделать сортировку в обратном порядке

Мне кажется, что найденные варианты работают не так. Используются они оба, а какой именно - зависит от того, что именно вы тестируете - запрос или ответ.

Если говорить про "запросы к БД", то для таких тестов "массив с данными" использовать просто глупо. Это получится какой-то формальный тест: "проверяем, что метод возвращает массив из трех строк - и тут же возвращаем этот самый массив". В чем смысл? Если вы тестируете запрос к БД, то и надо тестировать запрос к БД. По-другому никак.

Здесь я отвлекусь, и порассуждаю на тему того, что на самом деле тестирование - это гораздо более трудоёмкая задача, чем обычно считается. И как следствие, большая часть тестов - это такая вот туфта. Либо тест заранее возвращает нужные данные, либо тестирует один-два кейса. А вариантов неправильных входящих данных ведь может быть огромное количество. То есть по-хорошему на такой заведомо сложный (и принципиально неделимый!) метод нужно десятка два тестов.

И сюда же использование для тестов БД другой системы. Например основная БД MySQL, а для тестов используется Sqlite. Тут сразу можно сказать, что это профанация. Различие даже в какой-то одной настройке БД может повлиять на результаты запроса (и теста как следствие) - а тут и вовсе используется совсем другая БД.

С другой стороны, работу с БД скорее стоит тестировать не в юнит тестах, а скажем в интеграционных. Но не будем углубляться.

Массив же "с данными, симулирующими ответ из базы данных" используется на следующему уровне, там где требуется "ответ из базы данных". Взьмём метод, который использует данные, полученные из БД. Например авторизация юзера. Этот метод должен не сам лезть в базу, а дёргать отдельный метод, вполне возможно, что совсем другого класса. И вот чтобы протестировать авторизацию, вы и мокаете метод для работы с БД, и из этого мока возвращаете тот самый массив без всякого обращения к бд.

Здесь нелишне будет напомнить название доклада с одной из последних конференций по пхп. Дословно не помню, но что-то вроде "Делайте методы как можно короче. Ваши тесты скажут вам спасибо." Собственно, именно при тестировании очень быстро начинаешь понимать удобство атомарных (то есть выполняющих какую-то одну простую операцию) методов. А без тестов пройдёт довольно много времени, пока не понадобится этот длинный метод отрефакторить, и по итогам менять кучу кода, который его вызывает.

Так что разбивайте ваши длинные методы на мелкие, и тогда вопрос, как их тестировать, в большинстве случаев отпадёт сам собой.

Вопрос очень важный. Он показывает, насколько изменились подходы к программированию за четверть века.
Вот этот детский лепет - - происходит прямиком из прошлого века. Именно так писали на РНР3, в 1998 году.

С тех пор прошло уже 25 лет, а пехопа всё так и пишет РНР немного подрос, и проверять ошибки при работе с БД вручную стало не нужно. А чтобы увидеть ошибку, надо всего лишь включить вывод ошибок РНР. На домашнем сервере достаточно просто написать в начале скрипта

ini_set('display_errors', 1);

(и не забыть поставить 0, когда код поедет на боевой).

Соответственно, блок кода "игнорируется" просто потому, что ошибка является фатальной, и выполнение скрипта останавливается, ещё до всех этих if ($conn.

Документацию полезно иногда читать.
В ней шрифтом по фону написано, что

To use a literal instance of a special character in a regular expression, precede it by two backslash (\) characters. The MySQL parser interprets one of the backslashes, and the regular expression library interprets the other.

Я только недавно начал изучать программирование

Это очень похвально. Только ради бога, учите его по нормальным учебникам, а не по видеокурсам, которые делали неграмотные дети на мамкином ноутбуке.

Поскольку вы используете PDO, то можете сразу получить трехмерный массив, сгруппированный по одному полю

function listContactsByDepartment ($pdo){
    $sql = "SELECT 
    t3.department, -- обращаем внимание на эту строчку. Она должна быть первой
    t1.id,
    t1.full_name,
    t1.email_user,
    t1.tel_number,
    t2.filial,
    t3.department_email,
    t4.position,
    t5.number
    FROM contact_work AS t1 INNER JOIN filial_work AS t2  ON t1. id_filial = t2.id 
    INNER JOIN department_work AS t3 ON t1. id_department = t3.id
    INNER JOIN position AS t4 ON t1. id_position = t4.id
    INNER JOIN number_work AS t5 ON t1. id_number = t5.id
    ORDER BY `t2`.`filial` ASC , `t3`.`department` DESC ";
    return $pdo->query($sql)->fetchAll(PDO::FETCH_GROUP); # Обращаем внимание на эту константу
}
$contacts = listContactsByDepartment ($pdo);

Из этой функции вы получите трехмерный массив, который выводится двумя вложенными циклами

<?php foreach($contacts as $department_title => $department_contacts): ?>
                      <tr>
                        <td colspan=10><?=htmlspecialchars($department_title) ?>
                      <tr>
    <?php foreach($department_contacts as $row): ?>
                      <tr>
                        <td><?=htmlspecialchars($row['filial']) ?></td>
                        ...
                      </tr>
    <?php endforeach ?>
<?php endforeach ?>

• include "https://сайт/include.php"; - это идиотизм, и не должно работать. и не будет. Можно сразу забыть и идти исправлять на нормальные пути. Будет гораздо быстрее чем ныть здесь.
  Можно попробовать заменить на include $_SERVER['DOCUMENT_ROOT']."/include.php"; если это свой сайт. Если чужой, то просто выкинуть эту строчку совсем. Ну или попробовать заменить на file_get_contents
  
• include "include.php"; будут работать, если указать абсолютный путь. Хотя бы так,include __DIR__."/include.php";, но в некоторых случаях может не сработать
  
• если инклюды "заработали" после добавления AddHandler application/x-httpd-php .php .html .shtml .htm в файл .htaccess, это значит, что не работали не инклюды, а не работал РНР в html файлах. Он как бы и не должен, но на этом кривом сайте видимо такое использовалось. В любом случае эта строчка никакого отношения к инклюдам не имеет.
  

Потому что при работе через API запросы должны выполняться по одному, а не кучей.
Все эти точечки с запятой предназначены для консоли, а через API с мультизапросами всегда будут проблемы (даже если у какого-то умника в его песочнице с куличиками проблем до сих пор не было).
Потому что API предназначено для выполнения запросов по одному.

Тем более что здесь нужно всего три запроса, а не 100500. Множественная вставка делается не так, а одним запросом. При этом, как нас учат в первом классе, запросы должны быть параметризованными а не вот это вот всё.

Дополню предыдущий ответ правильным кодом, без вот этих всех бессмысленных телодвижений, которые понатыканы в исходном вопросе.

$query = "UPDATE `users` SET `address`= ?,`phone_number`=?  WHERE email=?";
$params = [
    $address,
    $phone_number,
    $email,
];
$stmt = $pdo->prepare($query);
$stmt->execute($params);

Только орфографические ошибки в именах полей поправил