0

I need to be able to prompt for user input (username, password and authorisation code) so my tests can access a GUI. These details cannot be stored as test data, so they'll have to be input part way through a test.

I've tried the following, but it's not working how I want:

Feature file:

Feature: user input as part of a test

  Scenario: user input at the start
  Given the test requires a name

Step definition:

Given(/^the test requires a name$/) do
  get_a_name
end

Method:

def get_a_name
  puts "Gimme a name"
  @input_name = gets.chomp
  puts "Hello #{@input_name}"
end

Result:

Gimme a name

Hello Feature: user input as part of a test

Any help would be much appreciated. Thanks.

Peter
  • 69
  • 4
  • 2
    Automated tests are supposed to be automated. Not pausing for manual input. Why can't you store that data somewhere?? You don't need to put credentials in the source code; you can use an `ENV` variable or a "secrets" (i.e. either an encrypted, or not-in-source-control) file. – Tom Lord Jun 27 '18 at 17:23
  • Or as an absolute last resort, why not fetch that data at the **start of the suite** instead of buried inside a specific feature? As the test suite grows, you could easily find yourself re-entering credentials multiple times, over a longer and longer period. – Tom Lord Jun 27 '18 at 17:25
  • As Tom said, you are defeating the point of an automated test. This is what property files are typically used to do. See, for example [How to load a value from properties file in Cucumber-jvm step class](https://stackoverflow.com/questions/36936970/how-to-load-a-value-from-properties-file-in-cucumber-jvm-step-class). – MikeJRamsey56 Jun 27 '18 at 17:36
  • Can't store the data because the authorisation code is generated via a third party, is unique to the user and the time they log on. It changes every minute or so. When a user logs on to the GUI they input username and password, then are prompted for the auth code. Once past the log-in, it's a regular GUI. – Peter Jun 28 '18 at 09:36
  • Peter, add the above to your question and you will have a better question. Then we can suggest ways to get around this issue – diabolist Jul 03 '18 at 10:13

1 Answers1

0

You have a number of options when dealing with external services in test automation. In this particular case you can

  1. Change your source so the authentication behaves differently when testing

OR

  1. Record a response from the external service and use that response instead of going to the external service (see https://github.com/vcr/vcr). As the response is recorded you will know the authorisation code

OR

  1. Use a test version of the external service which gives back know responses

I suspect there are a number of other solutions, but all three of the above are used widely and work fine.

There is certainly no need to have manual interactions to test your system unless you are running your tests against a production system (which is a very bad idea!).

diabolist
  • 3,990
  • 1
  • 11
  • 15