Free Pascal => Beginners => Topic started by: Weiss on September 10, 2022, 03:47:05 am

Title: how do you test run unit?
Post by: Weiss on September 10, 2022, 03:47:05 am
 how experienced programmers do it? For example, when I build a new function into the unit, I ended up writing a separate little program to call that function. Is it how it is done, normally? Testing new function by running main application seem a bit too slow, I usually need to get through the workflow to get to that specific function. But, smaller test programs cannot be too small either, because function might be designed for manipulation of large multi-dimensional arrays. I can't feed a few values from keyboard to properly test the behavior of my new function. Test programs ( I have written a few lately) could bloat into hundred lines of code. See my dilemma?

Is there a limit to how many units can be used by main program? What is better, to pile up functions into a unit, or make another unit? I am having a lot of fun, but would appreciate a bit of advice.
Title: Re: how do you test run unit?
Post by: 440bx on September 10, 2022, 04:36:35 am
by now, I"ve lost track of what's "normal" in testing.

I'll share the way I go about it. 

if the routine is a "utilitarian" type of routine which is used in different ways and in a lot of places in the program or in multiple programs, I'll code the routine and a test program (or more than one if necessary) to ensure the routine works as expected in all cases. An example of such routine would be formatting a hex number a specific way depending on some options (e.g, is there a separator between words, a separator between dwords, can the separators in both cases be different in various calls and, so on.)

for routines that are specific to the program, i.e, not general in nature, I'll set aside files that test specific code paths in the program and, often manually create files (derived from that set) that test code paths for which I couldn't find a test file but, know that specific case can occur.

A debugger is often an excellent testing tool when first developing the routine.  It's wise to step through the routine's code a line at a time ensuring every possibility is accounted for.

For mass verification of results, the solution is very dependent on what the program does.  Sometimes, it is necessary to add code that logs important results just to enable "mass verification" of those results against "known to be correct" results.

As far as units, the rule of thumb is to group routines in a unit based on their logical function.  Routines that are logically closely related should be placed in their own unit.

Piling up a bunch of unrelated or loosely related functions in a unit quickly becomes a hassle because in that case it becomes difficult to visualize the various logical blocks that come together to make the program.

I don't know if there is a limit on how many units a program can use but, if there is one, I haven't run into it.  That said, it is unusual for a unit to have a legitimate reason to use more than - roughly - 50 units.


Title: Re: how do you test run unit?
Post by: mas steindorff on September 10, 2022, 04:39:53 am
for me, it depends on how the unit is used and the GUI.  Since most GUI are dummied down for the end user, I find I need to design a "diag" GUI to do real testing and monitoring of the unit.  My tester tries to break things so best not to expose it to the end user.  but with 30+ units under my belt, I find it is best to keep this test GUI in the same unit so as things get updated and new bugs are found and fixed/detected new test needed in GUI. 
Within the unit to be tested, I create a Frame with the test code buttons, memos,... built in.  The frame use is optional in the final GUI but is added to a panel in the "diag" GUI. This works well as a place for the unit to pipe debug messages to as well.

Title: Re: how do you test run unit?
Post by: JLWest on September 10, 2022, 04:45:45 am
Well I'm no expert and the is the first post I have answered: So here goes.
For me it depends on how much the (new) performs or processes.

I sometimes build a quick and dirty demo program and test it. Sometimes with a load of a data file to provide data for the testing. The last one took 2 days.

Other times I run through the code with the debugger and try to test various functionality hoping to cover all the possibilities.  In my main unit I will sometimes enter an exit statement and an Inc(x); {Debug} I will stop on the Inc(x); checking what it's doing up to hitting the Inc(x). Once I'm satisfied I decide where to cut the demo code into the main program or a unit I usually call utilities.

On adding units I only put functions and procedures  that don't require fileUtil.  String manulaption, math calcs. 
Title: Re: how do you test run unit?
Post by: Leledumbo on September 22, 2022, 08:58:29 am
I'm surprised nobody mentions either FPCUnit or FPTest, provided that we have both for years and even possible to write unit tests that work with both, differing only in the program file. This is the my standard testing method, as I'm used to do the same in any other languages, be it Java, PHP, C, Go, whatever. The test indeed another program, but it tests individual functionality of each unit (function/method/whatever) and every time a change is done to the unit, you rerun it to ensure the change doesn't break anything else. External resources such as databases or 3rd party services can be made abstractions for and you make mock objects for them, therefore, your test doesn't rely on 3rd party solution that may be broken anytime.
Title: Re: how do you test run unit?
Post by: Thaddy on September 22, 2022, 01:00:41 pm
I am a bit bemused, but not really surprised.... :( But you are right Handoko. People are lazy.
Title: Re: how do you test run unit?
Post by: mas steindorff on September 22, 2022, 09:07:47 pm
I am a bit bemused, but not really surprised.... :( But you are right Handoko. People are lazy.
isn't that why we use the "write once" compiler?  ::)
I need to check out FPCunit but the other FPTest is a separate download outside the standard FPC package. That means it is not tested as much as (I hope to believe) the FP release code is.  and That means more testing of 3rd party software for me  %).

Anyway, proper test sequences are ones you can customize for the unit under test and it's "public" functions. The ones you have access to externally, should have limit and over range protection built into them.  What I need to test is the interworking of the class which is either built into the class, or I need a to attack the weak links of the class.  Therefore I tend to need the test code in the same file as the unit under test as part of a tFrame.
Often, the unit itself can detect it's in a bad state or has an error to report but does not have direct access to a log file or user interface.  That is where I tend to add debug hooks to my Classes.
a simple example
Code: [Select]
TdbgInfo Procedure(str:string) of object;

Tmyclass = class
  fDbgPnt :TdbgInfo;
 property debugPrintout:TdbgInfo read fDbgPnt write fDbgPnt;

procedure TmyClass.ShowError(str:string)
  if assigned(fDbgPnt) then

Then the owner object decides what to do with any debug / added info that the class can provide during runtime. 

TinyPortal © 2005-2018