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.# MakefileDEFINES=-DDARRAY_LIMIT=100all:        gcc $(DEFINES) my_app.cThe 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.export DEFINES=-DARRAY_LIMIT=10make -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?
Practices to build test vs release versions of code?
unit testing;builds;make