3
@lolcat_decorator1
@loldog_decorator2
@lolrat_decorator3
def lolanimal(*args, **kwargs):
  ....

I am sure I will unit-test those decorators separately. But these decorators will do stuff to the parameters passed to lolanimal first, and then lolanimal will do stuff to those modified parameters (one of those decorators may insert new keyword arguments to **kwargs.)

So what's the best way to mock it?

Thanks

CppLearner
  • 16,273
  • 32
  • 108
  • 163
  • Why are you using decorators? This seems like a textbook case for inheritance. – Silas Ray Apr 24 '12 at 16:37
  • Somebody in my team figure it was a good idea to use decorators. Well... I can't go back. Too many codes are using that :( I mean decorators are just functions. I guess I can patch them...just wondering if people actually have a better idea? – CppLearner Apr 24 '12 at 16:41

2 Answers2

4

My first thought would be to create a _lolanimal method that encapsulates all the actual functionality of lolanimal and then just make lolanimal a pass through wrapper around _lolanimal. Then you could just run all your tests against _lolanimal with data you fully control.

You also might be able to create a second decorator that would come before the first that would read a config value or something for some sort of testing mode that would override the lolspecific decorator if the config value is true...

Silas Ray
  • 25,682
  • 5
  • 48
  • 63
0

My first thought was that you should consider the decorators as part of the implementation of the function, and unit test the "function", hopefully you won't need to inject the dependencies into those decorators though - if you do, then Silas Ray's answer would need to be considered.

Arafangion
  • 11,517
  • 1
  • 40
  • 72