I was asked a question about unit testing based on this code:
Here is the question - “Can I write asserts inside this block itself?”. And a great tremor was felt in The Force.
For those who are unfamiliar with this concept, it is a far reaching design guideline that can help us create code that adheres more effectively to the SOLID design principles. It also forces us to keep our code focused on the underlying behavior of each concern and to make better choices about how each concern will interact.
In computer science, separation of concerns (SoC) is the process of separating a computer program into distinct features that overlap in functionality as little as possible. A concern is any piece of interest or focus in a program. Typically, concerns are synonymous with features or behaviors. Progress towards SoC is traditionally achieved through modularity of programming and encapsulation (or "transparency" of operation), with the help of information hiding. Layered designs in information systems are also often based on separation of concerns (e.g., presentation layer, business logic layer, data access layer, database layer).
There is, however, one area that is never discussed in terms of its being a “concern”, but should be - testing. The same level of effort should be applied to testing (and by this I mean unit testing), as to the design of a UI or data access layer. In fact, the amount of time spent on testing should be more than any other concern, as it applies to all other concerns. This also means not putting debug code into your production code. That is a concern of testing, and should be treated as such.