On 12/12/2016 2:47 PM, Michael Ryan wrote:
I wonder how much training would be required to implement TDD?
I'm a simple viola player. Didn't go to university. Learnt on the job.
I didn't get any TDD training, but I manage it well enough. I read
some articles, tried it with Java (JUnit) and fell over myself when
Mihael released RPGUnit. You can't imagine my glee when Thomas made it
into an RDi plug-in.
That's a lot of words to say that the principle seems pretty easy, and
with RPGUnit, the implementation is, too.
/copy rpgunit1/testcase
assert(buckGetMemberType('BUCK/QRPGLESRC(BUCK)') = 'RPGLE':
'Member type not RPGLE');
assert() tests the first parameter. If TRUE, do nothing, If FALSE,
issue the message in parameter 2. The first parameter here is an
expression. It fires my sub-procedure, passing in some parameters.
That sub-procedure returns a result (the source member type). If that
result is equal to 'RPGLE' then the expression evaluates to TRUE.
I could write one for each source member type I expect to return, but I
can also test other, edge conditions like this one:
assert(buckGetMemberType('BUCK/QRPGLESRC(DOESNOTEXIST)') = 'RPGLE':
'Member type not RPGLE');
Simply considering the code to make this test pass/fail means the
sub-procedure needs to do something when it runs into a source member
which doesn't exist. What should it do? An *ESCAPE message? A 'dummy'
returned source member type (all zeroes)? A separate 'error code'?
Doing this stuff early, while I'm still writing the initial
sub-procedure helps me consider all the weird edge cases, handle them,
and make sure they're in my test suite.
That's my
thought process - how can I get to more advanced methodologies when people
don't even develop the same way.
Shop standards seem to acknowledge that people are different, but also
that they ought to come together for the common good now and again. No
one would confuse my with Pollyana, but I think that TDD has enough
value that it might sell itself. I personally think that the biggest
issue IBM i programmers face is our self-imposed exile from the larger
community of developers. TDD sounds weird and strange to my colleagues
because they have /never heard of it/. That's one thing I can do; let
them know this stuff exists.
As an Amazon Associate we earn from qualifying purchases.