bdd - Re-using Python's behave feature file for both Unit and Functional tests -


the following gherking test defines desired behaviour 1 of servers:

  scenario outline: calling server valid json      given gis update server      when call /update json in file <filename>      response status code <status_code>      , response valid json      , response json contains key status      , response json contains key timestamp      , response json contains key validity    examples:   | filename                    | status_code |   | valid_minimal.json          | 200         |   | valid_minimal_minified.json | 200         |   | valid_full.json             | 200         |   | valid_full_minified.json    | 200         |   | valid_full_some_nulls.json  | 200         |   | valid_full_all_nulls.json   | 200         | 

i wrote code unit testing flask server. steps file, interpret gherkin directives, open test client , make necessary calls , assertions:

@given(u'a gis update server') def step_impl(context):     context.app = application.test_client() 

the feature file similar unit , functional tests. difference in few steps file have make http calls rather calling test client's methods.

what's right way re-use behave feature file passing parameters steps file?

expanding on parva's comments, suggest sending parameters via command line detected in step definitions , adjust behaviour unit vs functional testing (the decision of whether separate unit , functional tests clarity ;).

there example given in behave documentation around debug on error, gives example of using environmental attributes in modifying execution of steps method:

# -- file: features/environment.py # use: behave_debug_on_error=yes     (to enable debug-on-error) distutils.util import strtobool _bool import os  behave_debug_on_error = _bool(os.environ.get("behave_debug_on_error", "no"))  def after_step(context, step):     if behave_debug_on_error , step.status == "failed":         # -- enter debugger: zoom in on failure location.         # note: use ipython debugger, same pdb (basic python debugger).         import ipdb         ipdb.post_mortem(step.exc_traceback) 

you may change detect command line passed variable such unit_testing , have hit different endpoint or perform alternate functionality tests.


Comments

Popular posts from this blog

android - Get AccessToken using signpost OAuth without opening a browser (Two legged Oauth) -

org.mockito.exceptions.misusing.InvalidUseOfMatchersException: mockito -

google shop client API returns 400 bad request error while adding an item -