DUnit - Appropriate use??
Posted on 2004-08-23
I've been asked to look at DUnit for one of our existing projects, and I'm not really convinced it's going to be something that'll be easy to implement.
The project in question has around 200,000 lines of code in it. It's not based around any object oriented code at all (in fact, there is a ton of Delphi 1 legacy code still in it). There is a heap of inter-form dependencies - which may or may not be there depending on the way the method is called. So, we could have a component on Form2 that we're using, but only if the method is called in that particular way. Call it another way, and form2 may not even be looked at (or there for may not even be in memory).
Also, a single function may return many different results based on how it was initially called. What this means is, within the function, a set of different parameters are checked, and depending on those parameters, different formulas/actions are used which in turn returns a different result.
It's pretty much a dogs breakfast of code. It's been tacked onto for years now, and it's at the point now were changing something can bugger up other things due to it's heavy dependencies on shared stuff (that's bad sharing, not good sharing). The person who recommended we use DUnit believe that we can use it to fix some of these problems. I believe adding it into the program will just introduce even more issues and possibly won't work anyway due to the dependency issues.
Does anyone have any thoughts at all? I know it needs to be rewritten - and it will be. None of us have used DUnit before.
Any info greatly appreciated.