Although, the test is trivial, it already contributes to the design. The test has an expectation to the function interface: the input is two strings and the output is a string as well.

This implementation makes the test happy:

Funcsum(s1String,s2String):String{returns1+s2;}

Although, the test is green now, the code above is not TDD. The problem is that the code is way too complicated. Here is a better implementation:

Funcsum(s1String,s2String):String{return"";}

The test is green as well. But look into the implementation - it does exactly what the test expects and nothing more - the implementation returns non null result. It’s is important to mention that first implementation is not just complicated; it has a code path without any test coverage; for example, both “a+b” and “b+a” would keep the test green.

This is, probably(IMHO), the most important aspect of TDD, to make a test green, a developer must take a shortest path.

Now, when we have the test green with minimal possible implementation, it’s time for the next step. Make tests:

The test set from above is a full specification for concatenate() behaviour. It covers all edge cases as well. Why no null input scenario? The interface description states that nulls are not allowed. If someone will send a null, Null Pointer Exception will be raise, and this is ok (defensive programming is a topic for another day).

To make tests from above green, the function’s body get modified to:

Funcsum(s1String,s2String):String{returna+b;}

Another key point for TDD is the size of each step. Sometimes, a simple test case for a + b may result in a heavy development; imagine that strings must be validated by a remote service. For this cases, current test should be postponed and underlined features must be developed in TDD style. (Postponing is very convenient with Git branching)