Когда нужно начинать писать Unit тесты?

Дано: некая функция, которая пишется и отлаживается в LINQPad. Отладочный вывод через Dump. Пока 4 вызова.
Вопрос: есть ли какие-нибудь эвристики, по которым можно определить, что уже нужно начать писать юнит-тесты. Нужны какие-то критерии сложности, которые оправдывают применение NUnit(Lite). Стабов и моков пока нет.

Ответ

Unit tests
Для начала, юнит-тесты - это тестирование в изоляции, когда класс тестируется отдельно от остального кода (то есть, от других классов). Для изоляции классов друг от друга используется IoC (Inversion of Control), и обычно это DI (Dependency Injection). Соответственно, чтобы это по настоящему работало, хорошо бы знать, что такое IoC и DI.
Но, продолжая про юнит-тесты: следуя тестированию в изоляции, Вы не сможете написать тест, который тестирует один класс, если тот жестко зависит от другого. Вернее, конечно, сможете, но это будет не юнит-тест, а интеграционный (но, замечу, что есть некоторая путаница с определениями, что такое интеграционный тест). Если же Вы тестируете некую функцию на наборе реальных данных, то это - функциональное тестирование (но, опять же, есть некоторая путаница с определениями). И то, и другое, можно сделать при помощи того же NUnit, но не стоит путать их с юнит-тестами, они служат для разных целей!
Для чего нужны юнит-тесты: для упрощения создания хорошей архитектуры. Которая, в свою очередь нужна для облегчения внесения изменений в код. Иными словами, для облегчения ведения гибкой разработки (agile), для облегчения поддержки и так далее.
Для чего нужны функциональные тесты: для тестирования работы отдельных частей системы на реалистичных данных, чтобы избежать багов, связанных с вычислениями.
Для чего нужны интеграционные тесты: для тестирования системы или ее подсистемы в сборе, чтобы убедиться, что она выполняет то, что от нее требуется ее пользователям.
TDD
TDD правильно было бы перевести на русский, дословно, как "разработка, приводимая в движение тестированием", это сделало бы понимание чуть проще. Делается оно примерно так:
Вы осознаете, что Вам нужно написать класс. Вы пишете один юнит-тест (сразу нацеливаясь на IoC и DI) на метод класса. Вы пишете класс и тестируемый метод в объеме, достаточном, чтобы тест прошел. Повторяете пункты 2-3 до тех пор, пока класс не будет готов. Профит: класс, не связанный с другими классами - готов. Функциональный тест может писаться на этом этапе, если тестируемые методы не зависят от результата работы других классов. Интеграционные тесты можно писать, когда написана сама (под)система, которая уже может выполнять некую работу и обладает неким интерфейсом, к которому предполагается обращение "снаружи" этой системы, в том числе, и пользователем. Вот этот интерфейс и нужно тестировать, в том числе и на реалистичных данных.
Когда стоит начинать писать тесты
Если Вы пишете небольшой проект в течение 1-3 месяцев, а затем особое увеличение кода в нем не предполагается, то можно особо не заморачиваться с юнит-тестами. Проект достаточно мал, чтобы внесение изменений и правка багов не стали для него фатальны. Имеет смысл написать какие-то функциональные/интеграционные тесты на сложные алгоритмы. Но, тут важно грамотно оценить потенциал роста проекта. Если же предполагается достаточно длительная разработка, поддержка, возможно изменение требований и так далее, то тестирование необходимо, иначе Вы в итоге Вы получите кучу проблем на позднем этапе разработки проекта (обычно получается дикая лапша, в которой просто страшно что-то менять, так как сломаться после изменений может что угодно). В таком случае юнит-тесты стоит начинать писать сразу же. Единственное исключение - это прототипы (например, прототипы часто пишут в геймдеве, чтобы попробовать механику, посмотреть графику, показать инвесторам и т.п.). Важно помнить, что код прототипа не должен уйти в продакшн как есть, без переписывания по всем правилам!

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