Proper unit tests

[iluwatar]

Many of the pattern examples have used the convention to just run the main method as a lazy man's unit test but we need to improve this not to be bad example for anyone. The following examples need proper unit tests (I will not make separate issues but rather track this with the following checkboxes):

• [X] async-method-invocation
• [X] adapter
• [X] bridge
• [X] builder
• [X] business-delegate
• [X] chain
• [X] command
• [X] composite
• [X] decorator
• [X] dependency-injection
• [X] double-checked-locking
• [X] double-dispatch
• [X] event-aggregator
• [X] execute-around
• [X] facade
• [X] factory-method
• [X] fluentinterface
• [X] flux
• [X] flyweight
• [X] front-controller
• [X] half-sync-half-async
• [X] intercepting-filter
• [X] interpreter
• [X] iterator
• [X] layers
• [X] lazy-loading
• [X] mediator
• [X] memento
• [X] message-channel
• [X] model-view-controller
• [X] model-view-presenter
• [X] monostate
• [X] multiton
• [X] null-object
• [X] object-pool
• [X] observer
• [X] poison-pill
• [X] private-class-data
• [X] producer-consumer
• [X] property
• [X] prototype
• [X] proxy
• [X] publish-subscribe
• [X] repository
• [X] resource-acquisition-is-initialization
• [X] servant
• [X] service-layer
• [X] service-locator
• [X] singleton
• [X] specification
• [X] state
• [X] step-builder
• [X] strategy
• [X] template-method
• [X] thread-pool
• [X] tolerant-reader
• [X] twin
• [X] visitor

[npathai]

Totally up for it :+1: It would be good to have meaningful test cases with proper assertions.

[fluxw42]

Maybe it would be good to remove the AppTest classes, or at least annotate them with @Ignore. These app tests could give a false sense of great test coverage.

Removing these 'test' right now would cause a massive drop in coverage, but adding real junit tests over time should get this number back up, close to the original. You'll see the actual impact of your work when the number goes up, which is nice.

On the other hand, they show that the App at least runs without throwing any errors. What's your opinion on this?

[iluwatar]

I think it is good to have a test that runs the example and fails if there are errors. Therefore I would keep the existing AppTests. Some criticism has been presented that AppTests pollute the build output with the output of the examples. To address that I have been thinking about suppressing the console output when AppTest runs. However, I haven't researched how to do this yet.

[fluxw42]

@iluwatar Ok, I'll leave the AppTest junit tests in. The console output is not really a problem for me. When a test fails, additional logging could even be useful to find the issue.

[fluxw42]

The message-channel is marked as untested in this issue, but there is nothing much to test. This pattern only consists of one App class since it's using Apache Camel as message framework. There is an AppTest class, so could this pattern be marked as tested?

[iluwatar]

@fluxw42 you are right. I will tick the checkbox.

Edit: I just noticed that the same applies to publish-subscribe.