>>I do it by having the date be one of the function arguments and have the default be something like current_date. When I test I supply a date to override the default. This allows for testing the various scenarios by changing the supplied date.
With that approach you have to say application programmer - 'Hey dude, please edit this piece of code for my purpose and after that rollback it'. I think that it is unacceptable in large project...
CREATE FUNCTION do_some_date_based_stuff(reference_date date, other_args) [...]
CREATE FUNCTION production_wrapper_for_above(other_args) [...]
Easy to test do_some_date_based_stuff since it has fewer if any external dependencies. Shouldn't need to test the wrapper that simply calls the "do_some..." with a default value of the current date.
You might be able to define an appropriate function signature that avoids having to write the wrapper though regardless there is no need to have a different environment for testing versus production if approached in this manner. You just need to decide on the most desirable way to make it work.
