A: 

To answer your last question (re. JUnit), I would implement the following:

  1. a test for each valid input, confirming the corresponding output
  2. a test giving an invalid input and confirming that this scenario is handled appropriately (your interface may not permit invalid inputs if well-designed)

I wouldn't write one unit test checking each emotion/response. Why not ? If one test fails, then the whole unit test fails, and you won't know which of the further tests could be failing. When debugging determining the complete set of responses could be important, and a prematurely exiting test removes this capability.

Here's an introduction to JUnit (perhaps a little old, but still relevant)

Brian Agnew
Can you show how would be the implementation of both test cases as well as one which about checking emotion/response ?
Rachel
I can't easily do that since it's intimately dependent on your implementation. But you would simply perform assertEquals(expected, actual) for the response received from your code under test. See the tutorial linked above.
Brian Agnew
A: 

Following steps are extremely important for any development.

Requirement gathering

Freezing and documenting exact requirements. Drafting exact use cases help a lot.

Design

Designing the solution. Here different approaches can be chosen depending upon the nature of project.

  • Incremental pattern : For a long term project with short spurts of deliverables and reviews, an incremental pattern helps a lot.
  • Concrete pattern : Here you design your application in thorough. The releases cycles are longer. Every feature is completed first and then delivered.

Using UML following diagrams are important.

  • Class diagrams : Should list all classes in detail. Use of Interface, Abstract classes, helper classes, Third Party APIs can be detailed here.
  • Sequence diagrams : Should list the flow of actions for all listed use cases in project.

Use of appropriate design patterns should be included here. Test cases should be drafted matching the use cases, generally in relation like 1 or more test cases per use case.

There actually is a lot to describe here. What I have provided is the approach that should be taken while implementing the project.

Considering your application, breaking it down to different pieces can help design it simpler. On a broad level I can think of following pieces.

  1. Entity - Speaker, Listener
  2. Expressions - List of expressions
  3. Rules - Rules in the form of reaction expression for speaker expression.
  4. Communication - Communication layer which will be used by speaker to listener (something like a broadcast) and from listener to speaker(something like a point to point queue)
Tushar Tarkas