Навскидку сразу видно несколько проблем.
Во-первых, никакие тесты не должны изменять после себя базу. Если это интеграционные или приёмочные тесты, то их, например, можно проводить в транзакции, откатываемой после завершения каждого теста (кроме того, можно использовать in-memory DB — это заодно и ускорит выполнение тестов). А если это юнит-тесты, то они вообще не должны лезть в базу — надо переписывать код таким образом, чтобы юнит-тестирование не требовало обращений к БД (это, кстати, как правило и общее качество кода улучшает и делает код легче переиспользуемым).
Во-вторых, когда тесты выполняются часами — это верный симптом, что в консерватории что-то не так. Попробуйте отвязать тесты от БД — это должно сильно их ускорить. Если не поможет — разделите тесты по категориям и на каждый коммит прогоняйте только юнит-тесты, а интеграционные и приёмочные выполняйте раз в два-три часа (в зависимости от длительности их исполнения).
Кроме того, если все билды выполняются на одной машине, то их надо выполнять последовательно, а не параллельно — это уменьшает накладные расходы и общее время сборок/тестирования. А вот если вы выполняете сборки на разных машинах (например, TeamCity это умеет) — тогда да, можно запускать и параллельно, чтобы вычислительный ресурс не простаивал :-)
