Опять про юнит-тесты? :)

например, я не хочу иметь по всему коду длиннющие строчки получения форматированной даты последней субботы, это вынесено в ф-ю, и я ее просто вызываю. зачем сюда юниттэст?

Вопрос в том, что ты хочешь протестировать.

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

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

Когда коллеги обращаются ко мне с просьбой помочь написать юнит-тест, то мой первый вопрос: что ты хочешь протестировать? Правкически всегда этот вопрос сдавит в тупик :D И это, пожалуй, один из главных плюсов юнит-тестирования - разработчик должен понимать, что он тестирует. А потом уже можно будет решать вопросы о том как тестировать.

Я использую разбиение каждого теста на 3 части (подход Роя Ошеровава мне показался очень удобным и наглядным):

void TestName ()
{
  // Arrange
  ....
  // Act
  ....
  // Assert
  ....
}

Таким образом всегда видно, что именно тестируется и как работает unit under test.

но что даст такой тест, если хозяин сайта что-то изменит? тест и дальше будет проходить, но ф-я будет возвращать некорректный результат.

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