@wibeasley my first thought is that you could create a one-off user for every run on the demo site like this:

curl -d @user-add.json -H "Content-type:application/json" "$SERVER_URL/api/builtin-users?password=$NEWUSER_PASSWORD&key=$BUILTIN_USERS_KEY"

That's from http://guides.dataverse.org/en/4.18.1/api/native-api.html#create-a-builtin-user

I just tested it on the demo server and it worked with these environment variables:

export SERVER_URL=https://demo.dataverse.org

export NEWUSER_PASSWORD=password1

export BUILTIN_USERS_KEY=burrito

You'd have to vary the JSON you send each time to avoid errors about non-unique usernames or email addresses. In the link above this is what we provide as an example:

{
  "firstName": "Lisa",
  "lastName": "Simpson",
  "userName": "lsimpson",
  "affiliation": "Springfield",
  "position": "Student",
  "email": "lsimpson@mailinator.com"
}

Is there any chance that the real environments are not hit? You could create mocks and just make sure that the http request is being made with the right parameters.

Oh and to be clear the JSON response you get back should include the API token, which you'd use for subsequent operations. Using jq you could grab it like this:

jq '.data.apiToken'

But I assume you'd want to implement all of this "create user and assign the API token to a variable" stuff in R.

During a meeting Friday, @pdurbin tentatively planned that

• the initial test dataverses will be static on the demo server (e.g., https://demo.dataverse.org/dataverse/dataverse-client-r), as described in the initial post. As long as we're using only the demo server, we don't think it's necessary to keep the token secret, so we don't have to deploy environmental variables to Travis.
• accumulate tests until (a) we have good code coverage and decent corner-case coverage, and (b) the design that is stable
• add some dynamic features that follows @pdurbin's preference of ephemeral resources, such a the temporary users and dataverses. This will help the packages me deployed to things like Jenkins

@tainguyenbui, right now I think the mocks might be overkill for the current goals. I do appreciate that it could isolate problems of the client from problems of the server software. But the server seems pretty stable, and might require less maintenance that whatever mock I develop. Tell me if you think I'm overlooking something important.

Some thoughts from me (pyDataverse).

I think it would be great, to have a test-instance somewhere with the latest Dataverse version, so the clients can be tested there before (or after) the release. If there is one user for all, or one for each client, I don't know.

pyDataverse passes an API key if it is passed in the init of an Api() object.

Related is the idea of setting up a beta server that runs "develop" - IQSS/dataverse.harvard.edu#20

Also, a new instance of Dataverse is spun up after every pull request is merged at https://jenkins.dataverse.org/job/IQSS-dataverse-develop/ but then it gets terminated a few hours later.

Finally, https://demo.dataverse.org always runs the latest release. It's the officially blessed server for testing releases: http://guides.dataverse.org/en/4.18.1/api/getting-started.html#servers-you-can-test-with

If I understand this correctly and the decision is made, could you publish the dataverse on demo? I don't like the idea of writing tests that will have to be re-written.

@adam3smith I assume your question is for @wibeasley

You both have my blessing to publish whatever you want on https://demo.dataverse.org , especially if you're testing dataverse-client-r! 😄 🎉

Yes, this is referring to https://demo.dataverse.org/dataverse/dataverse-client-r which is unpublished, sorry for the confusion.