I have been bitten by the bug of automated unit testing. I feel the benefits and the confidence in a code base it can deliver.
I am also feel I have a reasonable intuition as to what parts of the code deserve to be unit tested. Code that has logic, code that might be messy (because it's dealing with some messy requirements) that you are happy to have encapsulated, that may have a few odd fringe conditions.
At my place of work, we leverage a number of tools which are fairly niche. For the sake of argument I can certainly see that these tools deliver on features and efficiencies making them indispensable for getting their particular job done.
The challenge I have is that I certainly have implemented logic in these tools which my gut says "this should be covered with a unit test".
I have tested these bits of code...
- In a throwaway fashion - try several inputs to exercise the code until satisfied it works - this has the downside of being lost effort when it comes to people maintaining the code in the future
- In a less throwaway but manual fashion - writing up the test cases and steps to poke the code to produce output; with test data; such that the above throwaway tests are not thrown away - this retains the investment in time, but is slow and subject to people knowing about the tests and running them
- In a slightly more automated fashion - with scripts to do the poking of the code; perhaps even check the output to a degree - this is more pleasant to re-run but is far from leveraging a mature framework in a consistent manner like when writing the xUnit style tests
While the progression feels nice, I feel I'm missing the xUnit experience I've become a fan of.
What kind of languages/platforms exactly am I dealing with here?
An ETL tool, akin to SSIS, called RedPoint Data Management: not open source so I'll describe, it has projects which have tools, these tools are linked by data flows, and some have some logic I wish to unit test
A composition tool, this for the uninitiated is a product which takes a data file and outputs a print file. Imagine XML in, PDF out.
DOS script functions: I promise this is a real feature of good'ol'fashioned DOS scripts, tutorial here
(I'll add this to the list, not strictly what I need help with, but may be more clear than the above if my tool set is difficult to empathise with) COBOL data transformations, using CopyBooks to specify the formats of the flat file inputs and outputs. When compiled results in one big-ball-of-mud binary even if functionally decomposed inside
The Actual Question
Are xUnit style tests fundamentally aimed at Object Oriented languages?