А если в конструктор параметр надо передать?

Если надо передать параметр, то это уже другой разговор. А зачем писать лишний код, когда параметры не нужны? :)

так из описания понял.

Тестируется функция, которая генерит пароли (aka последовательности символов).

К тому что по времени выполнения будет разница, вызывать функцию тысячу раз или миллион.

Это да, но количество вызовов не долго сказываться на работе самой функции. А если такие зависимости есть, то надо думать как их тестировать.

А можно примерчик вместе с вменяемой системой сборки, чтобы работала на любом компе, в любом месте при ограниченном времени без интернета.

Все смешалось кони, люди :D

Одна из подобных систем - Maven. Как я уже говорил, на последних двух местах работы я занимался разработкой подобных систем. Там процессы были "зашиты". У нас было много команд, которые делали свои компоненты. Компоненты разрабатывались в разных командах и независимо друг от друга. Там, где были логические зависимости (компонента А использует компоненту Б) мы делали соответствующую запись в БД. Таким образом продукт собирался из "верхних" компонент, а все "нижние" компоненты автоматически включались в продукт. Надо сказать, что работали мы исключительно с готовыми бинарниками (т.е. в репозиторий коммителись уже готовые бинарники). Ну а дальше все просто, у каждого компонента есть статус. И есть определенная цепочка прохождения по статусам. Например "Build Successful -> In Test -> Test Successful -> Aproved -> Released" или "Build Successful -> In Test -> Test Failed" или "Build Successful -> In Test -> Test Successful -> Rejected" ну и так далее, там много было цепочек. Кроме того, у каждой компоненты был тип: Alpha, Beta, Release Candidat, Release. Ну и дальше надо было собрать продукт (инсталлятор), для этого некий менеджер говорил "собрать продукт типа Release со статусом Released" и вжжжжжжик все компоненты собирались :) Новые версии могли создавать только те люди, которые разрабатывали компоненту, менять тип и статус - тоже.

Сначала коллеги конечно возмущались, что мол они всегда не так работали, а тут новая система, но потом поняли, что так лучше, чем "завтра надо отправлять клиентам, поэтому работает до 6 утра" :)

Очевидно, что на любом компе, в любом месте и без интрАнета работать это и не будет. Собственно говоря и не должно, т.к. продукт собирается на фирме и система сборки продукта - это часть инфраструктуры разработчика. Заказчику с этой системой работать не нужно, а потому требования о "любом компе, любом месте и без интернета" не состоятельны.

А в чем конкретные проблемы? Пока не попалось ни одного минуса, хотя долго боялся это делать.

Как ты говорил, либа Х используется как продуктом А, так и продуктом Б. Очевидно, что если каждый раз переносить все то в один продукт, то в другой (особенно если продукты эти развиваются параллельно), то встанет вопрос синхронизации либы Х. А это значит постоянные мерджы и конвликты в либе Х. Плюс к этому вечный риск того, что та или иная фича будет реализована в версии для продукта А и не будет реализована в версии для продукта Б. А это значит, что каждый продукт должен с особенной тщательностью. Я уж не говорю о том, что версии либы Х в разных репозиториях (и с разным функционалом) могут совпадать. Тогда вообще хвостов не найдешь.