Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I'm wondering how the few Delphi users here are doing unit testing, if any? Is there anything that integrates with the IDE that you've found works well? If not, what tools are you using and do you have or know of example mini-projects that demonstrate how it all works?
Update:
I forgot to mention that I'm using BDS 2006 Pro, though I occasionally drop into Delphi 7, and of course others may be using other versions.
DUnit is a xUnit type of unit testing framework to be used with win32 Delphi. Since Delphi 2005 DUnit is integrated to a certan point into the IDE. Other DUnit integration tools for the Delphi IDE can be found here. DUnit comes with documentation with examples.
There are some add-ons for DUnit, maybe this is worth a new entry on SO. Two which I can put on the list now are
FastMM4 integration: Unit tests will automatically detect memory leaks (and other things), works with DUnit 9.3 and newer
OpenCTF is a 'component test
framework' based on DUnit, it
creates the tests dynamically for
all components in the project's
forms, frames and datamodules, and
tests them using customized rules (open source)
You could take a look at the unit testing classes available in our SynCommons open source unit. It's used in our Open-Source framework for all regression tests. It's perhaps not the best, but it's worth taking a look at it.
See http://blog.synopse.info/post/2010/07/23/Unit-Testing-light-in-Delphi
In order to implement an unit test, you just declare a new test case by creating a class like this:
type
TTestNumbersAdding = class(TSynTestCase)
published
procedure TestIntegerAdd;
procedure TestDoubleAdd;
end;
procedure TTestNumbersAdding.TestDoubleAdd;
var A,B: double;
i: integer;
begin
for i := 1 to 1000 do
begin
A := Random;
B := Random;
CheckSame(A+B,Adding(A,B));
end;
end;
Then you create a test suit, and run it.
In the up-to-come 1.13 version, there is also a new logging mechanism with stack trace of any raised exception and such, just like MadExcept, using .map file content as source.
It's now used by the unit testing classes, so that any failure will create an entry in the log with the source line, and stack trace:
C:\Dev\lib\SQLite3\exe\TestSQL3.exe 0.0.0.0 (2011-04-13)
Host=Laptop User=MyName CPU=2*0-15-1027 OS=2.3=5.1.2600 Wow64=0 Freq=3579545
TSynLogTest 1.13 2011-04-13 05:40:25
20110413 05402559 fail TTestLowLevelCommon(00B31D70) Low level common: TDynArray "" stack trace 0002FE0B SynCommons.TDynArray.Init (15148) 00036736 SynCommons.Test64K (18206) 0003682F SynCommons.TTestLowLevelCommon._TDynArray (18214) 000E9C94 TestSQL3 (163)
The difference between a test suit without logging and a test suit with logging is only this:
procedure TSynTestsLogged.Failed(const msg: string; aTest: TSynTestCase);
begin
inherited;
with TestCase[fCurrentMethod] do
fLogFile.Log(sllFail,'%: % "%"',
[Ident,TestName[fCurrentMethodIndex],msg],aTest);
end;
The logging mechanism can do much than just log the testing: you can log recursive calls of methods, select the information you want to appear in the logs, profile the application from the customer side, writing published properties, TList or TCollection content as JSON into the log content, and so on...
The first time the .map file is read, a .mab file is created, and will contain all symbol information needed. You can send the .mab file with the .exe to your client, or even embed its content to the .exe. This .mab file is optimized: a .map of 927,984 bytes compresses into a 71,943 .mab file.
So this unit could be recognized as the natural child of DUnit and MadExcept wedding, in pure OpenSource. :)
Additional information is available on our forum. Feel free to ask. Feedback and feature requests are welcome! Works from Delphi 6 up to XE.
DUnit2 is available from http://members.optusnet.com.au/~mcnabp/
DUnit2 is modified more regularly than the original dunit. It also works on Delphi 2009.
Try: http://sourceforge.net/projects/dunit2/ - it moved as the original author Peter McNab passed away several years ago. Still some activity on the dunit mailing list.
There's a new unit testing framework for modern Delphi versions in development: https://github.com/VSoftTechnologies/DUnitX
Usually I create a Unit test project (File->New->Other->Unit Test->Test Project). It contains the stuff I need so it's been good enough so far.
I use delphi 2007 so I don't really know if this is available in 2006.
We do unit testing of all logic code using DUnit and use the code coverage profiler included in AQTime to check that all paths through the code are executed by the tests.
We have two approaches, first we have Dunit tests that are run buy the developers - these make sure that the code that has just been changed still works as before. The other approach is to use CruiseControl.NET to build executables and then run the dunit tests everytime a change is made, to ensure that there are no unintended consequences of the change.
Much of our codebase has no tests, so the automatic tests are a case of continuous development in order to ensure our applications work as we think they should.
We tried to use DUnit with Delphi 5, but it didn't work well. Specially if you are implementing COM interfaces, we found many dependencies to setup all the test infrastructure. I don't know if the test support has improved in newer versions.
Related
As the title suggest, I can't find that unit.
Is there an equivalent?
I am trying to port a unit from VCL to Firemonkey which contains OleServer in its uses clause, but I can't find any information on Embarcaderos website regarding this problem.
I have also tried to Google it, but no success.
Where can I find TOleServer and/or its unit OleServer that is compatible with Firemonkey?
Or how can I implement that unit in my Firemonkey project?
Hi i have the same problèm before and i made change in OleServer
Copy Vcl.OleSever to your project and rename it to FMX.OleServer
in implementation section do change like this:
implementation
uses
FMX.Controls;
resourcestring
sNoRunningObject = 'Unable to retrieve a pointer to a running object registered with OLE for %s/%s';
at the initialization section change to FMX.Controls.TControl
initialization
GroupDescendentsWith(TOleServer, FMX.Controls.TControl);
end.
Finally rename VCL.OleServer to FMX.OleServer in your imported library unit
Indeed the main issue with compiling TLB (typelibrary) units for COM/OLE Servers seems to be some unit renaming that has occured. Ideally the Delphi IDE should detect this automatically and fix it.
Based on Doug Rudd's comment above I fixed my "uses OleServer" to "uses Vcl.OleServer" in my TLB unit.
Since there's a "source" folder under Delphi installation folder even for the Pro version now (at least at 10.2.2 Tokyo version that I'm currently using), I could also easily spot (using GrepWin free tool) where the "EmptyParam" that was causing my TLB to not compile had gone. It is under System.Variants unit that one also needs to use in their TLB (before it was in System so you didn't need to use some unit for it).
Guess I could have imported the COM/OLE Server again to make new TLB import unit, but since it was hand-ended (to remove using of "Graphics", "StdVcl" and "OleCtrls" units that were bloating the executable size in older versions of Delphi) and that hand-edited imported TLB used to work fine for a command-line application, I didn't have any reason to reimport the Type Library.
You can see the changes I did to make my XSLer tool work with the latest Delphi at https://github.com/Zoomicon/tranXform/commit/e99f42049b8a4c1534d9edb78ed5e6493e6e5786. That XSLer command-line tool is using MSXML (Microsoft XML) automation server.
I trying to implement some basic automated testing on a 10 million LOC project that don't follow good OO pratices (ex: isolating business logic into classes/units) with the DUnit that comes along with Delphi 2010. I can't do normal unit testing on this project since each part of business logic is spread across a dozens of interdependent units, these 'groups' of units are, however, centered around certain 'main business logic screens' (ex: all invoice logic related units are centered on the main invoice screen), and since those screens are classes I can do 'main business logic screen class testing' instead of unit testing, but those 'main screens' still need a lot of stuff that is created during the process startup.
So I need to both:
Be able to run the bad project's startup stuff
Be able to access its objects
The bad project already have some exported functions that return pointers that I can cast to access it's objects, but I'm unable to call them either way:
If I create the bad project as a child process of the test process, the startup code run fine, but I can't find a way to call the exported functions without complex IPC methods or substantial change on the bad project's structure.
If I load the bad project's .exe as an dll as with the LoadLibrary function, calling any function exported by bad project's result in access violation and/or segfault errors, even this simple procedure:
procedure Test; {safecall;} {stdcall;}
begin
showmessage('Yay!');
end;
How can I do both?
The approach you're talking about (using exported functions) is not going to fly. The simplest form of communication between two Win32 programs is to have them use SendMessage or PostMessage to talk to each other. Locating the window handle (usually by window class name) is step 1, sending a message is step 2.
Secondly, DUnit gets you nowhere near your goal, and TTestCase cannot be extended neatly to be a GUI Controller as that's not what it's for. It's for unit testing. Round peg, square hole. Write TTestCases for classes you can hive off and test, and use DUnit to provide test coverage for those parts of your system that you can provide test coverage for.
For UI testing, use a completely separate framework. There are two basic approaches done by Delphi programmers for automated integration tests of the sort you're proposing.
A custom hack job. Such is what you are describing. Inside Embarcadero, there exists a framework which is called Zombie, something Nick blogged about back in 2007. Its approach is based on several kinds of "primitive IPC", usually involving a Win32 SendMessage or PostMessage window message from outside the program to a window handle of a control inside the program. However, the internal code IS SIGNIFICANTLY MODIFIED to permit zombie testing. No you can't have Teh Codez, they're internal and proprietary to Embarcadero. But it does illustrate that the approach does work, and does not require rewriting the whole application or writing a huge number of mock-classes, like unit testing
would have done. If you want to go down the hack route, you will be writing your own User Interface Testing Framework, which should probably be completely separate from and use no DUnit code. You are welcome to try, but I'm telling you, it's a serious impedance mismatch. If I was starting my own custom framework in 2013, it would be DCOM based, because Delphi DCOM server code could be simply conditionally compiled into many programs, and DCOM would handle the function call "marshalling" details for you. I suspect I would get a year into the project, and I would give up, because in the end, I doubt I could make any system (DCOM or Win32 message based) pay off.
A complete external testing tool which you write test scripts in, like AutomatedQA/SmartBear TestComplete. Your tests would not be compiled into a delphi test program, but run inside TestComplete, and Pascal-like script syntax is just one of the available options for writing your test scripts.
We have had the same problem here. It looks like you really need a delphi library project (*.dll) for the export functions to work, (I suspect no initalization of the framework takes place when calling the function directly on an executable, no warranties).
NOTE: We are still using Delphi 5, so no dunit intergration here.
The solution we've used is to adding the dunit sources to our project (the .exe project) with a conditional DEFINE, and use this conditional define in the startup unit.
Sample startup code from our application:
if ComServer.StartMode <> smAutomation then
begin
OurApplication.Login ;
end;
{$IFDEF _AS_TESTRUNNER_}
GUITestRunner.RunRegisteredTests;
{$ELSE}
if OurApplication.HasStartCommands then
begin
Application.ShowMainForm := False ;
end
else begin
if ComServer.StartMode = smAutomation then
Application.ShowMainForm := False
end;
Application.Run;
{$ENDIF}
OurApplication.Finalize;
When I use the _AS_TESTRUNNER_ conditional define, I must login first so our app (and db connections) get initialised. Followed bij the GUITestrunner of DUnit.
Testcases can be registered in the initialization part exactly as in the examples.
Works like a charm.
Is there a way to write unit tests so that they can be compiled and run both with Delphi and Free Pascal?
There are different unit test frameworks for Delphi and Free Pascal, which causes duplicate work for developers who target both compilers (for example, library and framework developers).
So maybe there is a way, using either the DUnit or the FPCUnit framework and tweak the test case source code (or the framework itself) so that it also works with the other compiler.
So essentially the question is:
which framework (DUnit or FPCUnit) can be compiled with both compilers (Delphi and Free Pascal) with as little modifications as possible?
or
is there a third framework (Thanks to Arnaud for mentioning TSynTest) which works with Delphi and FPC?
See this very nice blog article - just fresh meat about FPCUnit testing.
In short, as far as I know, and if you compare to DUnit:
Most Check*() methods were renamed Assert*();
SetUp / TearDown methods are called per-function in both framework;
Some other thinks may vary.
So, I think it could be easy to let FPCUnit "mimics" DUnit, by creating a small wrapper class over FPCUnit implementation, to have the same exact methods than with DUnit. So you may be able to share code between the two targets, and even re-use existing DUnit tests. Such a wrapper class is IMHO much more convenient that using {$ifdef FPC} as other suggested here. Conditional compilation tends to make code hard to debug, verbose, redundant and should be used only if necessary.
Another potential solution could be to use other tests frameworks. Our small TSynTest classes are lighter, but I'm currently converting the framework to FPC. So the same exact code could be used with both compilers. It has some features (like optional logging with fine profiling, and full stack strace on failure) which I would miss from DUnit / FPCUnit. It does not have a GUI nor a Wizard but honestly, as I programmer I prefer plain text that I can include in my technical release documentation easily to testify that no regression occurred.
Default unit test framework for Free Pascal is FPCUnit, it has the same design as DUnit but different from it in minor details. You can write common unit tests for FPCUnit and DUnit by circumventing the differences by {$IFDEF FPC}. I just tested FPCUnit, it is a usable framework, and blogged about it.
I just whipped up a sample that works in both DUnit (delphi) and FPCUnit (Freepascal equivalent nearest to DUnit, that happens to ship already "in the box" in lazarus 1.0, which includes freepascal 2.6 ):
A trivial bit of IFDEF and you're there.
unit TestUnit1;
{$IFDEF FPC}
{$mode objfpc}{$H+}
{$ENDIF}
interface
uses
Classes,
{$ifdef FPC}
fpcunit, testutils, testregistry,
{$else}
TestFramework,
{$endif}
SysUtils;
type
TTestCase1= class(TTestCase)
published
procedure TestHookUp;
end;
implementation
procedure TTestCase1.TestHookUp;
begin
Self.Check(false,'value');
end;
initialization
RegisterTest(TTestCase1{$ifndef FPC}.Suite{$endif});
end.
I'm trying to use DUnit, which came with RAD Studio XE2, to unit testing a Firemonkey app (C++).
The problem is, DUnit is a VCL project, and this makes me unable to include the Firemonkey Unit Forms (ex.: UfrmMain.h) on the testing project.
Even if I separate the Visual with Logic (MultiTier/MVC), i cannot include any Firemonkey library into my classes (sometimes this would be useful, when there is a class "CustomDatabase" which have a object of type TConnection, that is only available in Firemonkey - of course only an example).
The testing is possible when i separate the firemonkey code completely and leave it on forms, and the logic/data kept on classes with pure C++ code.
So, this "handicap" is actually a good thing? Forcing me to work with MultiTier/MVC? (This thing in C++ is new to me)
Or should i look for an alternative of unit testing, that lets me test forms too?
(Can you also recommend me some C++ project on github or code example which is separated in the mentioned way, where i can rely on?)
One possible approach would be to use TextTestRunner rather than GUITestRunner. I've never actually tried this but I think it quite plausible that TextTestRunner does not use any VCL units, or at the very least what it does use can easily be excised. And indeed a quick scan of the source code suggests that this will work.
Has anyone come across a framework or library for Delphi to simplify the generation of x86 code? I am not looking for an assembler, but rather a framework that abstracts the code generation process above the low level bits and bytes. Ideally I would like to build on top of an existing library or framework rather than hardcode the logic on a case by case basis.
The initial usage will be to generate small code stubs at runtime similar to the way Delphi dispatches SOAP requests. If I cannot find something I will likely roll my own, but I would hate to reinvent the wheel. Something in "C" might me interesting provided the license will permit translation and use in commercial and open source projects.
Update:
Here is some more context: What I am working toward is runtime implementation of interfaces and/or classes as part of a persistence framework. Something sort of like Java annotation driven persistence (JPA/EJB3) except with a distinctly Delphi flavor. The invocation target is a modular/extensible framework which will implement a generalized persistence model. I need to dispatch and hook method calls based on RTTI and an annotation/attribute model (something similar to InstantObjects metadata) in a very dynamic and fluid manner.
Thanks,
David
The more I have thought about your question. I am not sure if all you trying to just do Dynamic Method Invocation. Even though your asking about generating x86 code.
There are several techiniques that do this.
If you know the signature of the method in question you can do it easily by using a
TMethod and setting the method address and data.
procedure TForm8.Button1Click(Sender: TObject);
begin
Showmessage('Hello1');
end;
procedure TForm8.Button2Click(Sender: TObject);
var
M : TMethod;
begin
M.Code := MethodAddress('Button1Click');
M.Data := Self;
TNotifyEvent(M)(self);
end;
If you don't know the method signature you can write the class with {$METHODINFO ON}
Then use the functionality in ObjAuto.pas to invoke the method.
I have an example in my RTTI Presentation code from DelphiLive on how to do that.
According to features of PaxCompiler, you can create stand alone executable files.
Very spectulative answer:
Something like LLVM? I am not sure if it can be used from delphi or not, but you should be able to create dll's wth it.
Logically you would simply generate delphi code, compile to a DLL/BPL by cmdline compiler and then dyn load that one?
Unfortunately Delphi Explorer doesn't come with the cmdline compiler though. And your main binary would also have to be in Delphi Explorer (or at least in D2006 if that is binary compatible enough)
Any mix of Delphi versions (or Free Pascal) will probably not work on the package or HLL level, only at basic procedural DLL level.
I just found an interesting framework that does much of what I was looking for when I originally posted the question. A little late for my purposes, but thought someone else might find this useful:
DAsmJit a Delphi port of the asmjit project