Если ваш Singleton's предназначен только для инициализации один раз, у вас может быть код, который проверяет наличие повторной инициализации и регистрирует текущий стек, когда он обнаруживает это. Затем, если вы проверите стек, вы увидите, какой тест получил мяч, и вы можете проверить журналы JUnit, чтобы увидеть, что тест прошел прямо до этого.
С точки зрения решения этой проблемы более подробно, вместо того, чтобы ее обнаружить, я бы порекомендовал вам инициализатор синглтона, который помнит, что он инициализировал, и имеет один метод слежения, который срывает все, что он инициализировал. Таким образом, тесты могут быть сделаны только для инициализации через этот класс, и только нужно сделать одно дело в режиме срыва.
Я также думаю, что предложение Карла Манастера является хорошим, но если вы используете JUnit4, тогда у вас может быть метод срыва, который запускается в суперклассе, не забудьте вспомнить супер. Если вы не используете графический интерфейс JUnit3, JUnit4 должен быть заменой. Единственное, что нужно использовать в своих новых функциях, которые вы должны перенести на весь тест, вы не можете жить в одном классе. Таким образом, тесты, которые взаимодействуют с этими синглонами, должны были быть перенесены на один класс тестов за раз.
Разве сумма кучи не увеличивалась бы где-то между тестовыми прогонами - так как junit теперь должен записывать дополнительный TestResult? –
До тех пор, пока не запускается сбор мусора, память, используемая при первом запуске теста, не восстанавливается. – Mnementh