Original in Russian: http://18delphi.blogspot.ru/2013/03/dunit_29.html
About containers. Table of contents
Here we talked about patterns and mixins:
http://18delphi.blogspot.com/2015/02/containers-10-about-patterns-and-mixins.html
Now I’ll tell about the simplest use of DUnit framework.
The reasons WHY we need tests are given briefly here - http://18delphi.blogspot.com/2013/03/blog-post.html .
I think, in future I’ll give “real-world” examples.
Meanwhile, let’s just consider the technique by abstract example.
I will base on classes we’ve got in the previous example.
As usual, we’ll start with the diagram:
SandBox.dpr:
IntStackTest.pas:
StringStackTest.pas:
-- we’ve got tests of our classes’ workability :-)
As for me, it is cool. Especially if you run tests EVERY day :-) If we run them every day, we find out on-the-fly what is broken.
Don’t you dare say “it is VERY simple” :-) The devil is always in detail.
I’d try to give more complex examples “taken from life” further.
The main thing is that tests are a very simple way of debugging for many designed classes. Testing eliminates the need for developing a full-scale application wasting 10 minutes for compilation, for deploying database server and so on. One simply thinks up data out of his own head, writes a test and that’s it – he can debug this particular class.
It’s clear that you base on NAMELY THESE data. But nothing prevents us from gradual supplementing tests base and the base of “data from our own head”.
Later I’ll write about how I use mocks basing on etalon files.
Meanwhile read about the idea here:
https://en.wikipedia.org/wiki/Mock_object
If you ask to “show forms testing and GUI”, my answer will be “I’ll certainly show. I’ve got a wealth of experience”.
So far, concentrate on the fact that you should not be afraid to “touch” forms because they “stick out” for user. In contrast, be afraid to deal with base classes, especially if a few tens of different forms use them. Especially if they are written by “a guy who quit the job five years ago”. Especially if you don’t have tests. The more “base character” the class has and the more faults is found, the more tests will be written for it. One day. If you follow my recommendations. It will also become more stable.
Try it. May be you will like it.
The next series is here: http://18delphi.blogspot.com/2015/03/dunit-patterns-and-tests.html
About containers. Table of contents
Here we talked about patterns and mixins:
http://18delphi.blogspot.com/2015/02/containers-10-about-patterns-and-mixins.html
Now I’ll tell about the simplest use of DUnit framework.
The reasons WHY we need tests are given briefly here - http://18delphi.blogspot.com/2013/03/blog-post.html .
I think, in future I’ll give “real-world” examples.
Meanwhile, let’s just consider the technique by abstract example.
I will base on classes we’ve got in the previous example.
As usual, we’ll start with the diagram:
SandBox.dpr:
program SandBoxTest; uses TestFrameWork GUITestRunner, IntStack, IntStackTest, StringStack, StringStackTest; begin GUITestRunner.RunRegisteredTests; end.
IntStackTest.pas:
unit IntStackTest; interface uses TestFrameWork ; type TIntStackTest = {final} class(TTestCase) published // published methods procedure DoIt; end;//TIntStackTest implementation uses IntStack, SysUtils ; // start class TIntStackTest procedure TIntStackTest.DoIt; const cEtalons : array [0..3] of integer = (10, 20, 3, 5); var l_S : TIntStack; l_I : Integer; begin l_S := TIntStack.Create; try for l_I := Low(cEtalons) to High(cEtalons) do l_S.Push(cEtalons[l_I]); for l_I := High(cEtalons) downto Low(cEtalons) do Check(l_S.Pop = cEtalons[l_I]); finally FreeAndNil(l_S); end;//try..finally end;//TIntStackTest.DoIt initialization TestFramework.RegisterTest(TIntStackTest.Suite); end.
StringStackTest.pas:
unit StringStackTest; interface uses TestFrameWork ; type TStringStackTest = class(TTestCase) published // published methods procedure DoIt; end;//TStringStackTest implementation uses StringStack, SysUtils ; procedure TStringStackTest.DoIt; const cEtalons : array [0..5] of String = ('The ', 'cat ', 'sat ', 'on ', 'the ','mat'); . var l_S : TStringStack; l_I : Integer; begin l_S := TStringStack.Create; try for l_I := Low(cEtalons) to High(cEtalons) do l_S.Push(cEtalons[l_I]); for l_I := High(cEtalons) downto Low(cEtalons) do Check(l_S.Pop = cEtalons[l_I]); finally FreeAndNil(l_S); end;//try..finally end;//TStringStackTest.DoIt initialization TestFramework.RegisterTest(TStringStackTest.Suite); end.
-- we’ve got tests of our classes’ workability :-)
As for me, it is cool. Especially if you run tests EVERY day :-) If we run them every day, we find out on-the-fly what is broken.
Don’t you dare say “it is VERY simple” :-) The devil is always in detail.
I’d try to give more complex examples “taken from life” further.
The main thing is that tests are a very simple way of debugging for many designed classes. Testing eliminates the need for developing a full-scale application wasting 10 minutes for compilation, for deploying database server and so on. One simply thinks up data out of his own head, writes a test and that’s it – he can debug this particular class.
It’s clear that you base on NAMELY THESE data. But nothing prevents us from gradual supplementing tests base and the base of “data from our own head”.
Later I’ll write about how I use mocks basing on etalon files.
Meanwhile read about the idea here:
https://en.wikipedia.org/wiki/Mock_object
If you ask to “show forms testing and GUI”, my answer will be “I’ll certainly show. I’ve got a wealth of experience”.
So far, concentrate on the fact that you should not be afraid to “touch” forms because they “stick out” for user. In contrast, be afraid to deal with base classes, especially if a few tens of different forms use them. Especially if they are written by “a guy who quit the job five years ago”. Especially if you don’t have tests. The more “base character” the class has and the more faults is found, the more tests will be written for it. One day. If you follow my recommendations. It will also become more stable.
Try it. May be you will like it.
The next series is here: http://18delphi.blogspot.com/2015/03/dunit-patterns-and-tests.html
Комментариев нет:
Отправить комментарий