search

oveits / ProvisioningEngine

Ruby on Rails based ProvisioningEngine Frontend for provisioning of legacy systems via Apache Camel Backend (SOAP/XML+SPML+File import)
3 stars 6 forks source link

travisCI tests fail on development+master branch, while they are successfull on the old travisCI branch #14

Closed oveits closed 8 years ago

oveits commented 8 years ago

Need to troubleshoot the reason, why the travisCI branch is successfully built and tested on travisCI, while the development and master branches fail.

oveits commented 8 years ago

travisCI log reveals following problem:

1) On target solution 'Environment2_V7R1' synchronize all Users for testTarget == view should synchronize the index with the User objects found on the target system
     Failure/Error: expect(page).to have_link( "Synchronize #{obj}s" ) #, href: synchronize_provisioningobjects_path(obj) )
       expected #has_link?("Synchronize Users") to return true, got false
     # ./spec/requests/provisioningobjects_spec.rb:1174:in `block (6 levels) in <top (required)>'

Since I have introduced a new figaro variable (in config/application.yml that controls, whether or not the synchonize_all buttons are visible, I guess, I have introduced this new bug. I remember that I have set defaults for all other figaro variables in config/application.rb, but I have failed to do so this time.

In addition, from googling around, it seems that travisCI does not support to read in the figaro variables found in config/application.yml? Anyway, this file is kept secret/local, since it may include login credentials, and we do not want to expose those. Therefore, travisCI has no chance to know the content of this file and I need to set proper defaults, if I do not want to control all variables explicitely in the .travis.yml file.

TODO: 1) (prio: 1) add the default value of the new variables and set them to being visible 2) (prio: 2) once this is done, I also need to make sure that rspec tests are successful, even if the variables are set to "false" i.e. that the buttons are not visible. For this case, I need to adapt the rspec tests accordingly.

There is a small drawback of the second measure: if we allow for rspec testing with variable values, that cause some tests to be skipped (e.g. consider the synchonize button variable set to "not visible" causing all involved tests to be skipped), we may miss newly introduced bugs during manual rspec testing. However, travisCI will still find the bugs, if we make sure that travisCI is tested with the proper set of variable values (a set of variables that makes sure all features are tested).