0

I have classes that look like this:

Header (.h):

class DatabaseX ; //forward declare
class DeepClass
{ 
public:
  void DeepClass(DatabaseX* db);
  void doStuff();
private:
  DatabaseX *m_db;

};

Definition (.cpp)

#include "some/path/that/stretches/into/a/rather/deep/structure/DeepClass.h"
#include "another/somewhat/disturbing/long/path/to/somewhere/distant/DatabaseX.h"

void DeepClass::DeepClass(DatabaseX* db):m_db(db){ m_db->open() }
void DeepClass::~DeepClass(){ m_db->close(); delete m_db; }

void DeepClass::doStuff(){ // <complicated stuff here> }

Now I want a test that checks that doStuff() does the right kind of stuff.

So I write my own mock DatabaseX. But I have a problem, my own mock database lives in the test directory, it has no place in production code, and what's worse, DatabaseX was never written to be inherited and overloaded. It's a concrete class, and isn't anything like an interface.

So my question is, how do I write a test, with all these hard-coded include paths everywhere? Do I for example:

  1. create another duplicate file structure that matches the include paths, and put my mock DatabaseX there in this duplicate file structure?
  2. Somehow rewite each cpp file before the compiler accesses it by some indirection magic or other?
  3. Add macros to eat up the paths?
  4. Write a python/perl/bash script to temporarily remove the include paths prior to compiling my tests?
  5. Just include everything, accept the dependencies of DatabaseX, and just compile the real thing, and all it's dependencies and then replace at link time?
  6. Accept defeat; don't write any tests, and bury my head in the sand.
  7. OR ... ?

I should say there are well over a million lines of code, so changing the source code isn't an option. Is there a very simple way to overcome this nightmare via a nice simple compiler option or other?

(Perhaps it's not relevant but I'm using Qt's QTest & QtCreator. Maybe there is some magical switch that makes all these gruesome paths go away!).

I am using GCC 4.8.5

CodingFrog
  • 1,225
  • 2
  • 9
  • 17
  • Look at the "inlcude path" settings/command line options for your compiler. There should only be (short) relative paths in your include statements. Your structure also seems to imply that there is no distinction between "public/sdk" and "internal" header files. So some restructuring may be needed there as well. Oh and I have in practice done things like that in code bases with over 10 million lines of code. – Pepijn Kramer Dec 11 '21 at 11:37
  • There's no concept of public/private/internal. That's right. But the code base is littered with long include paths in the CPP files. – CodingFrog Dec 11 '21 at 11:46
  • Why isn't fixing up the paths an option? It shouldn't take more than a few minutes. – molbdnilo Dec 11 '21 at 11:51
  • Yes, very true. BUT, the paths were short, and then made long to speed up compilation (because the whole compilation time took too long), so the developers got what they wanted. There was no consideration for the poor testers! – CodingFrog Dec 11 '21 at 11:54
  • For me it seems no to be a technical problem! If your coders have no idea how to structure directures and set up well defined build systems and even get a hint from test colleagues did not change it, it is time to escalate! Non testable code ( for what reason ever ) is a no go for any tec company. Give your developers a chance to get the problem fixed, try to teach them. But if say stay on the bad side, it is time for HR to take decisions... – Klaus Dec 11 '21 at 12:45
  • I don't see how longer paths would increase compile time. Try splitting up de code into independent (!!!, dependency injection can help) small (static linkable) C++ libs with their own header files so that they can build in parallel. Really with a code base that large there should be more design (at a higher level then before), create a role in your organization to look after build/testing/development infrastructure and not leave it to the developers only. – Pepijn Kramer Dec 11 '21 at 12:47
  • @Klaus I think we agree, there is something missing in that organization – Pepijn Kramer Dec 11 '21 at 12:47
  • I think once they know I've tried to 'get around' these issues, and asked around, and considered what tools / rabbits I could pull out of my toolbox, they might start to realise there's an issue! – CodingFrog Dec 11 '21 at 14:06
  • Thanks guys for your input. The only way I can see any possible solution is to duplicate the explicit #include paths, and create a mocks at those locations, or write my own pre-processor! All rather messy/non-standard solutions. – CodingFrog Dec 11 '21 at 14:16

0 Answers0