Creating a Unit test which tests partial routines

I was wondering if anyone has ever created a unit test which would run testing a mac routine (old fashion), via 1. Setup all the variables.

2. Run a unit test on routine from line x to line x +100…

I know it sounds a bit odd, since line numbers do change, and therefore - these unit tests may not be as stable. 

Just curious if anyone ever wrote something like this.  Obviously in some older code there may be a routines out there which have 1000’s of lines of code, and testing the entire thing is extremely difficult, but testing a small logically bound chunks - would be useful.

Not sure if anyone came across this and how was it implemented.

Thank you,

Alex

  • 0
  • 0
  • 135
  • 5
  • 1

Answers

Alex - I think it isn't a smart idea to call into a specific line number of a routine since the contents will change.  Instead you should call the line labels/functions called within the routine by outside of the routine and pass all appropriate variables, etc that way.

Trying to call a specific line number will certainly lead to faster than desired 'bit rot' in your unit test library.

And if you don't have labels, adding them wouldn't break existing code.

For example you have this routine:

TEST
    write 1
    write 2
    write 3
    quit

It, when called would output

>do ^TEST
123

If you then add a label somewhere:

TEST
    write 1

MYLABEL
    write 2
    write 3
    quit

The routine would wok the same on previous calls:

>do ^TEST
123

But you'll also be able to call only the label:

>do MYLABEL^TEST
23

Thank you, I think that will work.  Adding a label does not seem to interfere with routine flow, so at least you can run a unit test starting from anywhere, but you still will have to run the routine to the end.

Either way, this is definitely an option if you wish to run a unit test from some point other the starting label.

Thank you,

Alex

Thank you Ben.  I realize there maybe an issue there.  I was thinking someone came up with a workaround (sort of speaking).  In either cases, I think labels would work well to test partial huge routines, but it will only alter the starting point, not end.  

You could (and probably should) separate these parts of routines as separate methods or at least subroutines.

Eduard - I completely agree!

The nice (or annoying, depending on your perspective) thing about moving to the discipline of unit testing is that it forces you to write your code in a more modular (and therefore more testable) manner, and refactoring to meet these goals is a great byproduct of a testing focus :)