Test Engine: Introduction

[acrm]

Overview

Currently we have got a quite simple testing system: for some method m1() we write a test method m1Test(), which transports input parameters for m1() and compare result with given correct output. If it match then m1Test() write to console successful message, otherwise failure message. To run a test we need to invoke test method from somewhere. We organize tests in test classes and organize tests invocations in RunTest-methods. To get total test report we need to call the most top-level RunTest-method. Also because of output of test report to console we cannot simultaneously run our tests and operate with our program console interface.

Maybe such system is generally acceptable so far, because currently we are just debugging our application and not producing any release version for our users (because we don't have a single). But if we would have, they won't be happy with test reports in their application console. On the other side I, as a requirements supplier, am quite interested in those test reports, to overview which functionality is working currently and haven't anything been broken after last commits.

A solution is obvious: we need to separate our application output from our tests output. And a good way to do it is to write our test reports not to console, but to a file. Users will not see it during using of application and I can read latest version of it if you add such report file to source control and include in your each commit.

The most straightforward approach to it - replace all writing to console with writing to file. It will take not so little time, because we have a few dozens of test and each contain writing to console. We can use Find&Replace but it worth to decide first on which code we will replace all our tests' Console.WriteLine(). For writing to a file we generally need more then one line of code, and it will take too much efforts if we found out later that we need to correct something in all occurrences of this lines.

Tasks

• [x] Suggest a good way to organize change in all tests' messages outputing.
• [x] Implement tests' messages outputing to a file
• [x] Add this test report file to source control and upload to repository

References

File I/O

[acrm]

Do you have any ideas? If it's clear for you, you can write your suggestion as a comment in this thread.

[acrm]

... In previous episode:

We decided to use events for coupling printing and messaging modules. To get familiar with events we started from self-made (as usual) events, implemented as public field of type Func<>. Everybody can put to that field any method for printing messages as wanted. And now...

Events: multiple subscribers

Overview

It is no cool that

Everybody can put to that field any method for printing messages as wanted

and there is just single field and if one message consumer is putting there his message handler, then others message consumer's handler being overwritten. Also, it's better if messaging module will not care about printing at all. This module just should provide for any other module possibility to notified about messages and how other modules will use it or will anybody use it at all - non of messaging module business.

Tasks

• [x] Implement the Observer pattern

[acrm]

Using event syntax

Good, know we have low-bounding between messaging and printing subsystems. The observer pattern is such commonly used (especially in UI) that C# have special keyword event for its quick implementation. In that terminology, a state change of some object that might be interesting for external users is called event. When this change is detected by some internal code of the object it's said that the event is raised. If other external objects want to execute some code right after the event is raised they have to add theirs event handlers to the object event. Event handler is just a delegate, i. e. reference to some method or lambda. The event member of class is equivalent to list of observers in Observable class from the pattern. Event handler is equivalent to observer. We can use any delegate type with void return type in signature (is it clear why void?), e. g. our old trusty Action, but there is a convention to use for event handling a delegate type EventHandler, or similar custom delegate type. Raising event is equivalent to invocation of each observer from the list.

Task

• [x] Rewrite tests-printer interaction using events
• [ ] Explain why event delegate should have void return type

References

MSDN: Events

[acrm]

Great! Now you can merge it to master