I've written an application which reads a list of filenames and does stuff on those files. Dynamic allocation is not allowed and our language of choice is C.

The app has an array to hold the filenames, and its size is determined by ARRAY_LIMIT in the Makefile, and used via C macro. The important bits of the Makefile look as follows.

# Makefile

        gcc $(DEFINES) my_app.c

The reason I've taken this approach is because I've written automated tests for this application, and part of this testing is to verify the behavior of the application at the borders of this limit. I also want to run the automated tests as I make changes.

My test script builds a test version of the code as follows.

# test_script.bash

# Overwrite the vars in the Makefile for testing.
make -e

# Do test stuff...

This will build the application such that its internal array size is only 10, instead of 100. This makes for significantly faster test runs.

TL;DR I've written an app for my team which is set up such that the build changes a quantitative aspect of its behavior based on if it's being made for release or unit test. We've hit code review and I'm facing pushback on this approach from the team lead. I don't want to change this aspect of the code because it has saved me many hours when modifying the application, and we have a more robust test phase later in our development cycle, which will test the release binary with the final large limits.

Is it harmful to allow build tools some leeway in program logic with the intent of creating test vs release versions?

  • Are you facing opposition on making the limits configurable (and thus testing a different binary than you are deploying)? Or are they only criticizing how you've implemented these limits and written the Makefile?
    – amon
    Jun 27, 2017 at 7:14
  • We have a test for the 'real' binary which we run later. That's what I meant by at the end by 'more robust test phase'. I'll edit to make that clearer. Jun 27, 2017 at 17:49

1 Answer 1


In general, having a compile time parameter for resource limits (and using it, for example, in a test scenario differently than in release scenario) is not particulary better or worse than having a run time parameter for the same purpose (as long as your program contains sensible bounds checks to not exceed the limit, and as long as your program code internally does not make any assumptions about the value of ARRAY_LIMIT). The only drawback is, whenever you want to change the parameter, you need to recompile the program, which means

  • there is an environment required where the compiler is available (which is probable not a restriction in your test environment)
  • it takes more time for the additional compilation step (which is probably mitigated by the fact your test will run faster)

Of course, there is one situation where your approach does not work: if the purpose of the test is to verify the behaviour of the exact, unmodified binary which will be delivered directly to production after it passes the test. You should clarify that this is not the goal here.

  • 2
    Customer wants MISRA. Jun 26, 2017 at 22:24
  • @DeepDeadpool: see my edit.
    – Doc Brown
    Jun 27, 2017 at 6:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.