Задача: есть сервисы которые принимают ряд входных параметров. Каждый сервис должен выполнять некую проверку на валидность параметров: не null, не пустая строка, больше нуля, меньше 100 и т.п. и при некорректных параметрах выкидывать соответствующий эксепшн.

Вопрос: как тестировать, что сервис проверяет входные параметры? Писать в ручную можно убиться, методов штук 20-50 и в каждом по 2-5 параметров которые надо проверить.

Что есть сервис? 

Я бы попытался накропать какой-нибудь механизм интроспекции - по java-коду, WSDL или что там у тебя есть. И пускай он в рантайме генерит вызовы.

Метод некого класса, который реализует бизнес логику, который как-то выставлен наружу.

А раньше о чем думали? =) Можно написать что-то вроде:
Но а) на это, мне кажется, уйдет не меньше времени б) читабельность будет не самая высокая, особенно если тест упадет.
По-моему, ничего страшного в написании обычных тестов нет, это логика, при чем достаточно простая, ее не так сложно проверить, проблема скорей в том, что эти тесты не писались постепенно по мере написании кода.
Ну.. с таким успехом можно и продукты купить, которые автоматически генерируют тесты по коду, закрепляя его намертво в текущем состоянии. Только от таких тестов не много проку.
Не ради "придраться", а лишь от любви к искусству замечу, что сервисы - это служебная (а не бизнес) логика, если на уровне сервисов у вас реализована бизнес логика, то это не самый красивый дизайн. По Фаулеру этот дизайн называется Transaction Script, а стремиться нужно к Domain Model.
PS: не пробовали заиспользовать программирование по контракту? Достаточно интересная тема как по мне, но сам еще не пробовал.

Может Fitnesse подойдет? раз два

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

Он и для него подходит.

Раньше это когда? Когда в программисты пошел?  


И что тогда должно реализовывать бизнес логику если не сервисы?


Не, не пробовали.





Интересная штука, надо будет нашим QA показать а то они по моему нечто подобное сами пишут 




Если бы было можно используя JSR-305 (или нечто похожее) и аспекты нагенерировать проверок входных параметров, меня бы это полностью устроило.

Не, когда код писали. Имею в виду, что 50 методов возникли не сами по себе и не за минуту ;) 
Доменная модель. А сервисы должны ее дергать.Ну это вполне реально. Только интересно - нужно ли затем тестировать правильно ли расставлены эти аннотации? Я б наверно не тестировал..

1. Бывает что код унаследован и надо его привести в порядок.
2. В моем случае этих 50 методов еще нет, но будут. Я просто пытаюсь облегчить себе задачу.




1. Как сделать такие предусловия?
2. А тестировать хотелось бы аргументы которые не помечены @NotNull 

Здесь обсуждались несколько реализаций из области программирования по контракту.

cofoja прикольная штука, попробую заюзать. Спасибо за наводку.

Мне неочень понравилось, что в cofoja'е PostconditionError это Error а не RuntimeException. Много кто работает только с RuntimeException, например Spring по умолчанию rollback'ит транзакцию только при RuntimeException но не при Error.