1.0.0 • Published 5 months ago

harpi_cli v1.0.0

Weekly downloads
-
License
ISC
Repository
github
Last release
5 months ago

harpi

  • Add command line variables override option
  • Also add to the ls if any view requires some input
  • Add error on not using required override
  • Support waitafter
    • Visualize by logging
  • Support naming of request
  • Support some session persistence of auto generated data
    • dont include non dynamic vars in session
    • exclude the harpi session files from test file search
    • harpi.gitignore
    • Print when and what the new session consist of
    • file inside dir is /harpisessions/session.notificationtest.harpi.yml
    • if the request is the first - regenerate session and keep the load in mem
    • for any request - load from that file
  • Support responsetime of each request
  • Support outputing the information to a file
  • Fix undefined session issue (when ls)
  • Fix datetime not serialized correctly
  • Never generate session when running ls
  • Fix toshortjson not handling non json
  • Fix when running quickly after another 408
    • Has something to do with the body
    • Apparently empty has some content length
    • Reproduce in local environment
    • was content length error because reuse same header object for everything
  • Error on no http verb
  • Make sure unsuccesful responses also do asserts
  • Fix creating new session if failed response in middle
    • This happens when an value assignment is being made unsuccesfully at that call as well
  • Figure out if should be able to choose if exit on error or not
  • Figure out how to assign multiple different values when key search replacing the same $(guid)
  • Decision records
    • Session
      • All dynamics are assigned
        1. At the beginning while running the complete test suite
        2. At the beginning of the single request if is the first request (id of first request is 1)
    • Dynamics
      • For now we will only support dynamics when defined as variable values
  • Test git ignore actually works

  • Extract filehandler write/read to external service

    • Create a branch
    • Code until failing test in harpifunctions
    • Consider moving file ext logic to file handler
    • Create new file
    • Remove findHarpiYmlFile func from harpifunctions.js
    • Make sure old logic in harpi functions file is now using filehandler
    • Code until filehandler test fails
    • test failing
    • Extract and test saveNewSession to fileHandler
    • Remove unused constants like "harpiGitIgnoreFileName" from harpifunctions
    • Remove old logic from harpifunctions
    • Remove last bits of fs from harpifunctions
    • Fix everywhere path combine is still hardcoded
      • SaveLogToFile
        • Moving the savelog logic to filehandler - right now test fails in harpifunctions - make another test fail in filehander test suite
        • Make sure the harpifunctions file uses the new method and has no other use for fs
    • Fix when value of variables ends with "==" is still included
    • Path things should be done exclusivly now that filehandler expects this
    • Check if okay to remove try catches
    • - Make sure non zero exit code on all possible returns
      • Rewrite so that index exits process with whatever response code the run method returns
      • No file found
      • When a single test fails
        • Make sure right thing is tested
    • Figure out security disable for when using in localhost
      • at source/repos/nodeapi
      • Create an example that fails first
        • run the content api via cli and use the test.harpi.yml - this fails when commented out
      • Make possible to turn on/off on cli param
      • Log guiding message if localhost as url
    • Figure out what would be a cool integration test
      • Make sure current test passes
      • The test should be against a local spun up api
      • get, post on validate, put on validate, delete on validate
      • Fix it waiting on the start api call
        • Appararently not as easy to run the api within a github action since no access to network interfaces, check how else to do this
        • Try curling it after starting to make sure its not running
          • Did not work
        • Research how to run a node api localhost in github actions
        • Try changing from localhost to "127.0.0.1"
        • Then try to run it with npx wait-on or some sort of wait on, since "the shell does not wait for the command to finish of &"
      • Create a simple docker implementation for testing with curl
      • Turn the node test api into the docker container
      • The current modified github actions does not work
      • Read documentation of how to run and request a docker container
      • Modify github actions to start docker container
      • Check via curl if runs in localhost
      • Verify all works
      • Add to wiki (with ubuntu etc)
    • Add npm test to the pipeline before other run
    • Rename github actions file
    • Make sure that the pipeline can run before merge
    • Cleanup notes
    • Run the pageindextest and verify all okay
    • Merge branch
  • Turn the docker test into a single big test that is runnable

    • Create branch
    • Research some ways to do this
    • Try copying the cli tool into the docker container aswell
    • Try writting a docker-compose file
      • Builds and runs the api
      • Installs and runs the cli tool against the api
      • https://www.freecodecamp.org/news/end-to-end-api-testing-with-docker/
      • Let the test image just ready the test
      • Move the actual execution of the test to the docker compose file
      • Try "docker-compose up"
      • Figure out why the api is not being run on "docker-compose up --build --abort-on-container-exit"
      • Make the port argument of dockerfile
      • Make the harpi test file exist in tests instead of tests/testapi
    • Rewrite github action to work
      • Check if it worked with last commit
    • Add the docker-compose to wiki
      • Make the baseurl argument of the harpi exe
    • We now have a cli command for docker build that can access /harpi dir and below: "docker build -t testapi -f tests/testapi/Dockerfile ." run from the harpi dir. Next step is to actually run the api from that directory so that it is still listening on that thread
    • Try explicit setting the context of the docker build to the root folder in order to access cli tool
    • Make sure that fail actually fails
    • Cleanup docker images
    • Consider making it runable by running "npm integrationtest"
    • Figure out how to run cli commands inside it
    • Verify by running test locally
    • Implement into github action
    • Merge branch
  • Documentation of the tool

    • Gather feature list from the pageindextest
    • Show cli param force "required"
    • Headers
    • Single exe
    • Create the example file of harpi and replace
    • Show waits
    • auto generated values:
      • guids
      • dates
    • Support downloadable example
      • Instead of git cloning - what should one do to download the file
  • Get live in npm
    • Verify all documentation by following clean install
    • Rewrite install docs
  • Make repo public

    • Consider hidding commit history
    • Consider single example with all features
    • Document the created files
    • Document session
  • - Support xxx form encoded

    • - show in ls
  • write hackernews letter
  • Allow for imperical variable ref inside variable

    • this should work with replace: variables: myvar: $(guid) myroute: "www.item.com/api/$(myvar)"
  • Dont trigger required error if single run and the single run does not contain the requirement

  • Research how microsoft yaml takes required parameters
  • Refactor the weird code that still sometimes creates new sessions even though bool param suggest is possible to turn of
  • Move these todos out of readme

Harpi

Harpi is a cli tool that executes .harpi.yml files which are simple text based http request scripts. The file format of the .harpi.yml files support sending http requests and asserting response data. Example:

variables:
  baseAddress: "https://test.com"
  itemId: "1" 
  itemTitle: "item 1"

requests:
  - name: "create data"
    method: "post"
    url: "$(baseAddress)/api/data/$(itemId)"
    jsonBody: 
      title: "$(itemTitle)"

  - name: "verify data now available"
    method: "get"
    url: "$(baseAddress)/api/data/$(itemId)"
    asserts:
      statusCodeEquals: 200
      javascriptAsserts:
        - name: "has expected title" 
          code: "response.title == '$(itemTitle)'"

The file can then be executed by using the "run" command

harpi run mytestfile.harpi.yml

Installing

npm install harpi

Example

Download the example script to your current directory

curl -O https://github.com/teslae1/harpi/example.harpi.yml

List the requests of the script

harpi ls MYTESTHARPIFILE.harpi.yml 

Run the script

harpi run MYTESTHARPIFILE.harpi.yml -v

Saving and using response data

It is possible to assign response data to a variable for later use:

variables:
  myResponseValue: #Assigned by first request
  baseAddress: "https://test.com"

requests:
  - name: "create data with auto generated id"
    method: "post"
    url: "$(baseAddress)/api/data"
    javascriptAssignments:
      - name: "save id of created item"
        code: "setSessionVariable('myResponseValue', response.id)"

  - name: "verify data now available at id"
    method: "get"
    url: "$(baseAddress)/api/data/$(myResponseValue)"
    asserts:
      statusCodeEquals: 200

Executing an individual request

It is possible to execute a single request - using the "ls" command all the http requests are listed with an id:

$> harpi ls myfile.harpi.yml
$> - request
$>   - id: 1
$>   - url: $(baseAddress)/api/data
$>   - method: post
$> - request
$>   - id: 2
$>   - url: $(baseAddress)/api/data/$(myResponseValue)
$>   - method: get

It is then possible to only execute request 2:

$> harpi run myfile.harpi.yml 2

Taking values as parameters

It is possible to take parameters from the command line - which then will be assigned to a variable. This is achieved by using the "required" keyword:

variables:
  token: required 
  apiKey: required

headers:
  Authorization: "Bearer $(token)"
  ApiKey: "$(apiKey)"

requests:
  - name: "verify data now available at id"
    method: "get"
    url: "https://test.com/api/data/2"
    asserts:
      statusCodeEquals: 200

This will now make it required to provide the defined variables when running the file:

$> harpi run myfile.harpi.yml --variables token=MYTOKEN,apiKey=MYAPIKEY

Headers

Example of setting headers for all requests

variables:
  token: required 
  apiKey: required

headers:
  Authorization: "Bearer $(token)"
  ApiKey: "$(apiKey)"

requests:
  - name: "This request will have both the headers defined in header"
    method: "get"
    url: "https://test.com/api/data/2"
    asserts:
      statusCodeEquals: 200
  - name: "This request will also have both the headers defined in header"
    method: "get"
    url: "https://test.com/api/data/2"
    asserts:
      statusCodeEquals: 200

Waiting between requests

It is possible to insert a wait between two requests:

variables:
  myResponseValue: #Assigned by first request
  baseAddress: "https://test.com"

requests:
  - name: "create data with auto generated id"
    method: "post"
    url: "https://test.com/api/data/1"
    #Waiting 500 milliseconds before executing next request
    waitBeforeNextRequest:
      name: "Waiting for data to be prepared"
      milliseconds: 500

  - name: "verify data now available at id"
    method: "get"
    url: "https://test.com/api/data/1"
    asserts:
      statusCodeEquals: 200

Auto generated values

It is possible to auto generate values like guids and dates. The values will be regenerated whenever the first request is executed

variables:
  currentDate: $(date)
  dateFiveMinutesInFuture: $(date.addMinutes(5))
  autoGeneratedId: $(guid)
  
requests:
  - url: "https://test.com/api/data/$(autoGeneratedId)"
    method: "post"
    jsonBody:
      someDateProperty: "$(currentDate)"
      anotherDateProperty: "$(dateFiveMinutesInFuture)"