meettya

ИМХО — проблема сложности написания тестов обычно вытекает из размеров тестируемого кода.
Сложно написать тесты на кусок в 2 csloc, который разве что кофе не варит.
Если изначально с кодом не сложилось и у вас легаси, то тесты можно будет прикрутить только после рефакторинга.
Расщепляете логику на небольшие куски, которые делают мало работы и покрываете эти куски тестами.

А сейчас у вас классическая проблема — вы пытаететь съесть слона целиком :)

PS. Интеграционные тесты — штука хрупкая, можно намучится, особенно если изменения часто в коде бывают.

btrfs использовать не стоит, при вываливании одного из хардов из массива ломается весь массив. Ну во всяком случае я НЕ смог собрать обратно, благо что как раз была помойка для торрентов, так что легко отделался.
mdadm + LVM + xfs — вот отличный вариант, именно в таком порядке.

«Будет база товаров (несколько сотен тысяч и расти), каждый товар может содержать произвольный набор данных, нужно делать выборку на запросы с произвольным набором параметров»
ИМХО — жесткая типизация параметров в отдельные справочники даст возможность быстрого выбора и сравнения, но расплачиваться будете скоростью заполнения справочника.
А по архитектуре — многоуровневый кеш и хорошое продумываение структуры базы. Если не боитесь — noSQL базы с map/reduce или колоночные БД. Будет зоопарк, зато (по идее) быстрее работать. Или хранить свойства в классической реляционной и хитрая материализация на чем-то типа Redis — поиск по параметрам — классический хеш, если я правильно понимаю задачу.