MrMig

Добавлю свое мнение (имею опыт разработки как энтерпрайзов, так и стартапов):

Spring Framework.

• Отлично подходит для крупных проектов, и проектов, которые необходимо будет длительно поддерживать.
  
• Желательно иметь 1 хорошего специалиста по спрингу, иначе скушает много времени на построение правильного процесса (все же это энтерпрайз-технология).
  
• Стандарт для энтерпрайза де-факто.
  

Grails.

• Пишется на груви (джава с сахаром + динамика), что объективно приятнее
  
• Отличное решение для прототипов и веб-CRUD систем.
  
• Имеет набор стандартных практик и кучу плагинов
  

Play 1.2
Концептуально это такой же фреймворк, как и Grails.
Главное не путать его с Play 2 (scala-фреймворк, переработанная архитектура. На джаве писать можно, но не удобно)

• Похож на греилс, но основноя язык — джава
  
• Низкий порог входа
  
• Использует стандартные джава-решения для связанных технологий (SQL ORM = Hibernate, к примеру)
  
• Подходит для прототипов
  
• Стейтлесс по умолчанию
  

Резюмируя — Спринг отлично подходит для средне-больших проектов, потенциально долгоживущих. Греилс и Плей — отлично подходит для прототипов и тестирования идей, а также для чистых веб-прослоек без страшной бизнес-логики.
Если вы хотите «попробовать идею в полевых условиях», я бы брал Play 1.2/Grails + AngularJS. Это позволит запилить прототип значительно быстрее, чем на том же Спринге.

Есть несколько разновидностей тестов. Если вы бэкэнд-разработчик, то вас, в первую очередь, будут интересовать два вида:

1. Юнит-тесты
2. Интеграционные тесты

Юнит-тесты — тесты, направленные на тестирование отдельных частей класса. Чаще всего это методы. Иногда — отдельные ветки методов (всегда справедливо для god objects).
Самый важный пункт: для юнит-тестирования не нужно поднимать контекст приложения! Вы тестируете логику отдельного юнита, а не связку классов. Поэтому, очень часто для юнит-тестирования использую мок-фреймворки (как пример — мокито). Это нужно для того, что не писать руками -заглушки связанных классов.

Что покрывается юнит-тестами? В первую очередь покрывайте бизнес-логику (сервисы, классы-менеджеры). После — контроллеры. Можно покрыть DAO-слой (опять же, если там есть сложная логика)0.

Как пишется юнит-тест? Вы берёте набор входных параметров, мокаете классы-зависимости, передаёте входные параметры в тестируемый метод и проверяете выходные параметры. Если в методе есть условия — необходимо попасть во все ветки.

Писать ли отдельный тестовый метод для каждой ветки? Это зависит от вашего стиля и от того, планируете ли вы рефакторинг в ближайшем будущем. По-хорошему, стоит выделять отдельные крупные ветки в отдельные методы, особенно для god objects.

Интеграционные тесты — это тестирование нескольких взаимосвязанных классов. К примеру, класс бизнес-логики + DAO-класс.
В случае интеграционного теста вам придётся поднимать контекст приложения (обычно для этого создаются отдельные конфигурационные файлы). К тому же, будет неплохо настроить транзакционность на уровне отдельных методов (для того, чтобы не чистить базу руками после изменений).

Нужны более глубокие подробности — пишите :)