I used Java before, and I could do anything with Eclipse. Now, because I want to use Delphi to modify an instant messaging software, I wonder how to move the reconstruction and unit testing system to Delphi. The book says that adding unit tests to existing code can deepen your understanding of the code and serve as a basis for improving the code. Isn’t this exactly what I want to do? So, in order to build such an agile platform, I made a small attempt with Delphi2005 and DUnit, and recorded the results below to share with you.
1. Download Delphi2005
Because Borland does not sell professional versions in China, given the sky-high price of architects and enterprise versions, it can only download a D version from the Internet for personal use. Delphi2005 is relatively large in size, and Update1 also requires CD, so it is recommended to use BT to download the 2CD version. The seed address is as follows:
http://www.delphhifans.com/SoftView/821.html
2. Download the sp1 of Delphi2005
It is said that after applying this patch, it can be faster, but the patch is slow to install and you still need to use a CD. The download address is as follows:
http://www.delphhifans.com/SoftView/970.html
3. Download DUnit
https://sourceforge.net/PRojects/dunit/
4. Install Delphi2005+sp1
Note that there is a register in keygen and when installing, you must install the .net and win32 versions of delphi at the same time, but C# builder doesn't matter. Because if you only install the win32 version, the reconstruction function will be unavailable (this is a bug in delphi2005, which is manifested as an exception window of .net when refactoring).
5. Simplify Delphi2005
Because the .net version was installed at the same time in the previous step, delphi became very slow when starting. This can be achieved by modifying the registry and deleting some IDE packages. The specific method is to add the parameter -rxxx after the Delphi shortcut target, that is, BDS.exe -rxxx. This xxx is for you to specify, and then you will find those damn packages in HKEY_CURRENT_USER/Software/Borland/xxx (this is the name you selected xxx)/3.0/Known IDE Packages. Note that you cannot delete it too cleanly like other win32 purified molecules on the Internet, as it will be useless for reconstruction. A relatively simple list I have obtained after experimenting many times is as follows
"$(BDS)//Bin//vclmenudesigner90.bpl"="(Untitled)"
"$(BDS)//Bin//win32debugproide90.bpl"="(Untitled)"
"$(BDS)//Bin//htmide90.bpl"="HTML Designer Package"
"$(BDS)//Bin//iteidew3290.bpl"="Borland Integrated Translation Environment for Win32"
"$(BDS)//Bin//SrcManIDE90.bpl"="(Untitled)"
"$(BDS)//Bin//todoide90.bpl"="Borland ToDo"
"$(BDS)//Bin//htmlhelp290.bpl"="Borland HtmlHelp Viewer"
"$(BDS)//Bin//idefilefilters90.bpl"="IDE Filefilters"
"$(BDS)//Bin//startpageide90.bpl"="Borland Start Page IDE Package"
"$(BDS)//Bin//refactoride90.bpl"="Borland Core Refactoring Package"
"$(BDS)//Bin//dbkdebugide90.bpl"="(Untitled)"
"$(BDS)//Bin//exceptiondiag90.bpl"="(Untitled)"
"$(BDS)//bin//deployide90.bpl"="Deployment Manager"
"$(BDS)//Bin//plugview90.bpl"="Pluggable Tree View Package"
"$(BDS)//Bin//coreproide90.bpl"="Core IDE Pro Package"
"$(BDS)//Bin//IDETools90.bpl"="Build Tools"
"$(BDS)//Bin//unittestide90.bpl"="(Untitled)"
"$(BDS)//Bin//historyide90.bpl"="(Untitled)"
"$(BDS)//Bin//htmltidy90.bpl"="HTML Tidy Formatter"
"$(BDS)//Bin//HTMLFmt90.bpl"="HTML Internal Formatter"
"$(BDS)//Bin//mlcc90.bpl"="Markup Language Code Completion Package"
"$(BDS)//Bin//delphivclide90.bpl"="Delphi VCL Designer IDE Package"
"$(BDS)//Bin//delphicoreproide90.bpl"="(Untitled)"
"$(BDS)//Bin//win32debugide90.bpl"="(Untitled)"
"$(BDS)//Bin//htmlide90.bpl"="(Untitled)"
"$(BDS)//Bin//delphide90.bpl"="Delphi Win32 IDE Personality"
"$(BDS)//Bin//mtspro90.bpl"="(Untitled)"
"$(BDS)//Bin//mtsent90.bpl"="(Untitled)"
"$(BDS)//Bin//iteidenet90.bpl"="Borland Integrated Translation Environment for .NET"
"$(BDS)//Bin//NetImportWiz90.bpl"="(Untitled)"
"$(BDS)//Bin//DataExplorer90.bpl"="(Untitled)"
Although it is still a bit slow to start, it can finally bear it.
6. Compile and install DUnit
Use the method you know to compile DUnit into dcu and put it into the directory you specified. And add this directory to the Library Path of Delphi Tools->Environment Options->Delphi Options->Library-win32.
Also compile DUnit.exe
7. Establish a project
The way I recommend is to separate the interface and the background when writing a Delphi program, specifically to open two projects, one ordinary VCL project and the other DLL project. No, no, I don't mean to let you share code in DLL. This DLL project contains files that are all background content, as well as tests on the background. The generated DLL is used for DUnit, from which DUnit can read out the test and run it. In fact, the project in the GUI part contains all the files. That is to say, it is better to add a DLL project specifically for testing on the basis of the original single project.
The project is divided into three parts: GUI, Core, and TestCore. Project one includes GUI+Core, and Project two includes Core+TestCore. The output of Project 1 is the Win32Exe program. The second output of the project is the Win32Dll program.
Then you can put these two projects into a Project Group.
8. Write tests
Project 1 is no different from writing a Dephi program. Remember to divide the functions of the GUI into the background and make the background testable. Tests are written in Engineering No. 2, and I call the name of Engineering No. 2 Core. Let’s add a basic test to Core to check whether 1+1 is equal to 2.
Create TestCase
unit TestBasic;
interface
uses
TestFramework;
type
TBasic = class
public
function Add(a, b: integer): integer;
end;
TTestBasic = class(TTestCase)
Private
FBasic: TBasic;
public
procedure SetUp; override;
procedure TearDown; override;
published
procedure TestAdd;
end;
Implementation
function TBasic.Add(a, b: integer): integer;
Begin
Results := a + b;
end;
procedure TTestBasic.SetUp;
Begin
FBasic := TBasic.Create;
end;
procedure TTestBasic.TearDown;
Begin
FBasic.Free;
end;
procedure TTestBasic.TestAdd;
Begin
CheckEquals(2, FBasic.Add(1, 1));
end;
Initialization
RegisterTest('', TTestBasic.Suite);
end.
Modify Core.bdsproj (KAO, what weird suffix)
Change begin end. to
exports
RegisteredTests name 'Test';
end.
And add TestFramework in the Uses section.
DUnit uses this export function to find the TestCase we registered in the dll.
9. Run DUnit
Add DUnit to the Tools menu, it's much more convenient. It's just that the parameters are difficult to fill in. I didn't use the macro inside, I just filled in the absolute path. If you fill in the absolute path like me, then select DUnit from the Tools menu and you can directly see a test list. Click Run and you will see a green light on.
If you are not adding DUnit to the Tools menu, you need to find the DLL compiled from the Core project, core.dll, from the file selection window of File->Load Test.
———
So far, there are both refactoring functions and unit testing. All that is left is to add tests to existing code and then slowly refactor them.