Day 044 - Some OOP groundwork

Owned by David Harms
Last updated: Apr 26, 2013Version comment
3 min read

Before I get into WinDev's object-oriented programming capabilities I think I need to spend a bit of time on some of the basics of declaring procedures/methods. 

Full disclosure: I'm a fan of strongly typed languages. I like to know exactly what data types I'm dealing with, and I'd rather deal with the restrictions imposed by strong typing than with the uncertainties of weak typing. We all have our own preferences. 

Without getting into the many definitions of strong and weak typing, I'll just say that from what I've seen so far WinDev is biased toward the weak side, at least when it comes to parameters. That means more flexibility and (at times) less readability. 

I decided that to really understand how all of this worked I wanted to set up some unit tests and write a bunch of methods. 

And although I'd been through this earlier in the tutorial, I found it a bit difficult to get my first tests off the ground. 

One of the things I wanted to do was test procedure overloading, so I created a class that looked like this:

MyClass is class
END

PROCEDURE Constructor()

PROCEDURE Destructor()

PROCEDURE MethodA(intValue is int)
RESULT intValue

PROCEDURE MethodB(value)
RESULT value

I wanted to create a unit test to verify that these methods returned what I expected them to return. 

But how to create the test? I right-clicked on the Tests node in the project explorer. No joy there, just a couple of non-applicable context menu items. 

On the project dashboard I clicked on Tests and got this window:

That was helpful - WinDev recognized my new class and pointed out I had no related tests. So I clicked on New test, and then on the New blank test icon, which gave me a Scenario1 entry in the test explorer: 

I double-clicked on Scenario1 and saw this:

I have to admit that didn't help me a whole bunch. So I went back and did some reading, and discovered that if I right-clicked on one of my methods in the project explore and created a test from there, I got a test scenario that looked like this:

Much more helpful - I could see where and how to create my object instance and call the method.

Controller1 is the expected value, which is listed in the non-code view of the scenario:

Besides getting back up to speed on unit testing I spent a fair bit of time today just looking over the docs for procedure parameters and return values. I'll get into those specifics tomorrow.