How to test the "totally untestable"

Original in Russian: http://programmingmindstream.blogspot.ru/2014/02/blog-post_4473.html

Right here - http://programmingmindstream.blogspot.ru/2014/02/blog-post_15.html . I’ve tried to give a detailed description of the “untestable” architecture testing “algorithm” and making it “testable” somehow.

Let’s view it from a different angle.

Suppose, we have a “principally untestable application”.

Let’s consider the “MOST TERRIBLE” case.

We do everything in the OnClick “handler” on the FORM, at the same time, the DATA from the database are being PROCESSED.

Namely:

It is MONOLITHIC and works with DataSet's on the form.

Something like this:

type
 TMainForm = class(TForm)
  DataSet: TDataSet;
  Grid: TGrid;
  Button: TButton;
  Label: TLabel;
 end;//TMainForm
 
procedure TMainForm.ButtonClick(aSender: TObject);
begin
 Label.Caption := Grid.SomeRow.SomeCalculations;
end;
...
begin
 Application.CreateForm(TMainForm, MainForm);
 Application.Run;
end.

Let’s test it:

We change the code of the project in a way:

...
begin
 Application.CreateForm(TMainForm, MainForm);
 GUITestRunner.TGuiTestRunnerForm.Create(Application); 
 // - we add the window with a “tests launcher”
 Application.Run;
end.

We add a test:

unit MyTest;
 
interface
 
uses
 TestFramework;
 
type
 TMyTest = class(TTestCase)
  published
   procedure DoIt;
 end;//TMyTest
 
implementation
 
uses
 MainForm // - HERE we KNOW about the MAIN form of the app
 ;
 
procedure TMyTest.DoIt;
var
 l_Form : TForm;
begin
 for l_Form in Screen.ActiveForms do
  if (l_Form Is TMainForm) then
  begin
   TMainForm(l_Form).Button.Click;
   l_Text := TMainForm(l_Form).Label.Caption;
   CompareWithEtalon(l_Text);
   break;
  end;//l_Form Is TMainForm
end;
 
initialization
 TestFramework.RegisterTest(TMyTest);

Do you understand the idea?

Of writing the CompareWithEtalon?

Of finding “that” TMainForm?

Of ensuring “repeatability” of a test?

Of ensuring the “database state”?

These ARE the QUESTIONS – JUST SO.

They can be DISCUSSED!

But!

Did the application STOP to be “untestable”?

Didn’t it?

There ARE QUESTIONS.

Many questions.

But!

We can discuss them.

“As it goes”.

But they “can be discussed” not in ABSTRACT – “what should we do if all went wrong”, but quite SPECIFICALLY in terms of “what should we do if we have THIS SPECIFIC problem”.

I hope, I have outlined another “one of the ways” how to test the “untestable application” and how to “turn away” from “cows in vacuum”.

P.S. It is obvious that “it is “the most real “white box”. But we have to START WITH SOMETHING! I mean, considering we do not have a “maid”...

P.P.S. It is also obvious that HERE the issue is neither “GUI tests”, nor “integration” tests, MUCH LESS it is “atomic” tests. The issue is ONLY writing of a “whatever test”, kind of “giving a start”, “raising” of the INFRASTRUCTURE.

When you have written a dozen of such “one-eyed, ill and obscure” tests, eventually, “it would be easier for you to do”. I am ALMOST POSITIVE about it :-)

You’d begin to refactor both tests and the code, getting rid of the “illness” and “Cut'n'Paste”.

And it would “work by itself”.

By and by, you’d get “correct” tests:
1. “Atomic” test.
2. “Integration” tests.
3. Regression tests.
4. GUI tests.

And the “one-eyed and ill” will BE GONE.

THE FIRST IS THE WORST!

Start with “something”.

P.P.P.S. It is obvious that raising of MODAL DIALOG is the GREATEST PROBLEM. It is also a QUESTION, that CAN and HAS TO be discussed.

But it is already a QUESTION, more than a “cow in vacuum”.

P.P.P.P.S. Right here - http://programmingmindstream.blogspot.ru/2014/02/anemicdomainmodel.html?showComment=1392717297690#c4055365633171954826 . – I’ve been “thrown to a challenge” :-)  I ACCEPT it :-)

Vsevolod sent a project to me to test.

More about testing