Десять человек уже тут написали — проверять содержимое БД нужно в том же тесте, который данные создаёт. И тогда вопрос очистки или неочистки БД вообще не будет стоять. Arrange, Act, Assert.
Василий Банников, ну так они же не от процесса резолва появились, как в ответе написано, вот я о чём.
Иван Шумов, на всякий случай поясню — по сути вы всё правильно написали, только не очень понятно и некорректно в деталях. Но и первое и второе важно для новичков, поэтому я и полез уточнять, а не чтобы вас как-то принизить.
Давайте, посоветуйте. Что в вашем ответе должно быть мне очевидно?
Когда оказалось, что после «резолва конфликта при мердже» остаются какие-то конструкции, я понял, что ничего очевидного дальше не будет и решил уточнить.
Поясню на всякий случай — резолв как раз подразумевает, что никаких конструкций не осталось, он от них избавляет.
Ну, ладно, я по контексту и последующему комментарию, кажется, понял, что автору предлагается исправить у себя, а потом заслать правку в основную репу. Но то, что это следовало из формулировки «просто сделать pull request где просто не будет» — ни разу не очевидно, тем более для людей, которые со всем этим на «вы».
Вот там же нужно проверять и то, что данные реально были обработаны и сохранены. То, что приложение не упало, ещё не значит, что всё работает как надо. А выносить проверку в отдельный тест — это очень странно.
Что значит "изначально кавычек нет"? Откуда у вас берётся эта строка? Как она выглядит в исходном виде? Как выглядит код, которым вы пытаетесь его декодировать?
Смотря какое время жизни вы указываете. И как часто у вас идут запросы к нему. Вроде, для файлового кеша нет механизма удаления устаревших значений, только замена. Но в этом я не уверен.
Ну а вообще, это так-то нормальное поведение, если вы cache:clear выполняете из под какого-то другого пользователя - либо рут, либо www-data должен это делать.
