OpenEuphoria

1. Unit-testing in same file

• Posted by SnakeCharmer Jul 27, 2012
• 1267 views

Is it possible to test function in same myfunc.e, not in separate t_myfunc.e? For example, I need Luhn algorithm for verifying credit cards.

http://rosettacode.org/wiki/Luhn_test#Euphoria

When this file will be started, it will check an algorithm correctness. It that is necessary for me. But if I import this file to the program, the constant cc_numbers is imported and the for-cycle will be executed, which are absolutely not necessary to me. Besides it would be desirable not to lose possibility of the automated testing. By the way, Python is able to do such trick by means of checking how the file is started - as the separate program or as the imported function:

if __name__ == "__main__" 

P.S. It would be absolutely amazing, if Euphoria would have something like Python's doctests. Here is how it could look for Luhn algorithm:

function luhn(sequence cc) 
>>> "49927398716"  --  Output effect of this input value should be... 
1                  --  ...such! 
>>> "49927398717" 
0 
>>> "1234567812345678" 
0 
>>> "1234567812345670" 
1 
-- Other part of function. 

3. Re: Unit-testing in same file

• Posted by mattlewis (admin) Jul 27, 2012
• 1227 views

The easiest way to do this is to put your code inside of an ifdef block:

-- mylib.e 
ifdef UNITTEST then 
  -- eutest mylib.e 
 
  -- tests go here 
end ifdef 

Then, under normal operation, the tests are skipped (the code isn't even parsed). But it's all there when you want to test it. When you call eutest, it automatically adds a "-d UNITTEST" to the command line when it invokes your program.

Matt

5. Re: Unit-testing in same file

• Posted by EUWX Jul 27, 2012
• 1129 views

A monolithic program with multiple includes is quite feasible and executable in Euphoria. Even Matt's own wxEuphoria can be considered monolithic. When I use it with about 20 files of my own 200 or so functions, with all files included at the beginning, there are no problems.

Namespaces were invented at the time when programmers were finding it difficult to give unique names to their functions. With due respect to the efforts of Euphoria programmers who use and are trying to convert everything to namespaces, I feel it is not necessary. Certainly the CPUs and the memory in the computers of today far exceeds what you can normal throw at them.

During development, I use the technique of calling all functions by their full names i.e. nm1:fn7 nm5:fn9 etc. I then use word processors to identify duplicate function names and apply corrections.

Perhaps, having been taught by teachers of the old school, I am old-fashioned, but a monolithic program calling functions in 20 different files in the same sub-folder works with me, using a larger amount of comments within each file and function.

Just my two-pence – no, two-cent's worth!

7. Re: Unit-testing in same file

• Posted by petelomax Jul 29, 2012
• 997 views

I would normally rework such code as:

constant cc_numbers = { 
    "49927398716",1, 
    "49927398717",0, 
    "1234567812345678",0, 
    "1234567812345670",1 
} 
  
for i = 1 to length(cc_numbers) by 2 do 
    if luhn(cc_numbers[i])!=cc_numbers[i+1] then ?9/0 end if 
end for 

and just leave it on permanently. If (and only if) I noticed a performance lag, I would add

constant TEST=0 
if TEST then 
  ... 
end if 

Pete

9. Re: Unit-testing in same file

• Posted by ghaberek (admin) Jul 29, 2012
• 958 views

IsHappy() needs to be declared as either public or export (or global, from pre-4.0) so that it becomes visible outside the scope of happy.e.

happy.e

include misc.e 
public function IsHappy(integer x) 

-Greg