As I was talking about in #196, I've been trying to figure out how to write JUnit tests for the menu classes. Without changing QueueProvider, I'd have to use System.setIn/setOut to test the menus.
Looking at QueueProvider, I'm thinking it would maybe work better as a singleton, and then a small hierarchy of QueueProvider like classes - a base, abstract class (or interface?) QueueProvider, with subclasses like TestingQueueProvider for testing, and other subclasses for standalone and server/client QueueProviders.
startMessenger() would then create the singleton instance variable in QueueProvider, which would be accessed with QueueProvider.getInstance() to use offer() and take() as before, or maybe getQueueProvider() which could be statically imported to make things a bit cleaner.
So that would make testing with the QueueProvider a lot cleaner (since you'd be overriding take() and offer() to store output etc) and also mean you don't need things like if (GameModeType.SERVER == mode)... in QueueProvider.
Just an idea. Is that too much?
As I was talking about in #196, I've been trying to figure out how to write JUnit tests for the menu classes. Without changing QueueProvider, I'd have to use System.setIn/setOut to test the menus.
Looking at QueueProvider, I'm thinking it would maybe work better as a singleton, and then a small hierarchy of QueueProvider like classes - a base, abstract class (or interface?) QueueProvider, with subclasses like TestingQueueProvider for testing, and other subclasses for standalone and server/client QueueProviders.
startMessenger() would then create the singleton instance variable in QueueProvider, which would be accessed with QueueProvider.getInstance() to use offer() and take() as before, or maybe getQueueProvider() which could be statically imported to make things a bit cleaner.
So that would make testing with the QueueProvider a lot cleaner (since you'd be overriding take() and offer() to store output etc) and also mean you don't need things like if (GameModeType.SERVER == mode)... in QueueProvider.
Just an idea. Is that too much?