update markdown files

Signed-off-by: Adam Ratzman <[email protected]>

Author: adamint

CODE_OF_CONDUCT.md

@@ -1,96 +1,10 @@
 # Contributing
 
-When contributing to this repository, please first discuss the change you wish to make via issue,
-email, or any other method with the owners of this repository before making a change. 
-
-Please note we have a code of conduct, please follow it in all your interactions with the project.
+When contributing to this repository, feel free to first discuss the change you wish to make via issue,
+email, or any other method with the owners of this repository before making a change.
 
+However, any library additions are always welcome. I am especially looking for the addition of new Kotlin/Native 
+targets.
 
 ## Testing
-Please see [testing.md](TESTING.md) for full testing instructions. Your contributions should be able to pass every test
-
-## Pull Request Process
-
-1. Ensure any install or build dependencies are removed before the end of the layer when doing a 
-   build.
-2. Update the README.md with details of changes to the interface, this includes new environment 
-   variables, exposed ports, useful file locations and container parameters.
-3. Increase the version numbers in any examples files and the README.md to the new version that this
-   Pull Request would represent. The versioning scheme we use is [SemVer](http://semver.org/).
-4. You may merge the Pull Request in once you have the sign-off of two other developers, or if you 
-   do not have permission to do that, you may request the second reviewer to merge it for you.
-
-## Code of Conduct
-
-### Our Pledge
-
-In the interest of fostering an open and welcoming environment, we as
-contributors and maintainers pledge to making participation in our project and
-our community a harassment-free experience for everyone, regardless of age, body
-size, disability, ethnicity, gender identity and expression, level of experience,
-nationality, personal appearance, race, religion, or sexual identity and
-orientation.
-
-### Our Standards
-
-Examples of behavior that contributes to creating a positive environment
-include:
-
-* Using welcoming and inclusive language
-* Being respectful of differing viewpoints and experiences
-* Gracefully accepting constructive criticism
-* Focusing on what is best for the community
-* Showing empathy towards other community members
-
-Examples of unacceptable behavior by participants include:
-
-* The use of sexualized language or imagery and unwelcome sexual attention or
-advances
-* Trolling, insulting/derogatory comments, and personal or political attacks
-* Public or private harassment
-* Publishing others' private information, such as a physical or electronic
-  address, without explicit permission
-* Other conduct which could reasonably be considered inappropriate in a
-  professional setting
-
-### Our Responsibilities
-
-Project maintainers are responsible for clarifying the standards of acceptable
-behavior and are expected to take appropriate and fair corrective action in
-response to any instances of unacceptable behavior.
-
-Project maintainers have the right and responsibility to remove, edit, or
-reject comments, commits, code, wiki edits, issues, and other contributions
-that are not aligned to this Code of Conduct, or to ban temporarily or
-permanently any contributor for other behaviors that they deem inappropriate,
-threatening, offensive, or harmful.
-
-### Scope
-
-This Code of Conduct applies both within project spaces and in public spaces
-when an individual is representing the project or its community. Examples of
-representing a project or community include using an official project e-mail
-address, posting via an official social media account, or acting as an appointed
-representative at an online or offline event. Representation of a project may be
-further defined and clarified by project maintainers.
-
-### Enforcement
-
-Instances of abusive, harassing, or otherwise unacceptable behavior may be
-reported by contacting the project team at [email protected]. All
-complaints will be reviewed and investigated and will result in a response that
-is deemed necessary and appropriate to the circumstances. The project team is
-obligated to maintain confidentiality with regard to the reporter of an incident.
-Further details of specific enforcement policies may be posted separately.
-
-Project maintainers who do not follow or enforce the Code of Conduct in good
-faith may face temporary or permanent repercussions as determined by other
-members of the project's leadership.
-
-### Attribution
-
-This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
-available at [http://contributor-covenant.org/version/1/4][version]
-
-[homepage]: http://contributor-covenant.org
-[version]: http://contributor-covenant.org/version/1/4/
+Please see [testing.md](TESTING.md) for full testing instructions. Your contributions should be able to pass every test.

CONTRIBUTING.md

@@ -1,26 +1,29 @@
 # Testing
 
-We use [Spek](https://github.com/spekframework/spek) to run unit tests. You must add Maven Central to the gradle repositories 
-in order to pull Spek.
+We use the multiplatform kotlin.test framework to run tests.
 
 You must create a Spotify application [here](https://developer.spotify.com/dashboard/applications) to get credentials.
 
-To run **only** public endpoint tests, run
+To run **only** public endpoint tests, you only need `SPOTIFY_CLIENT_ID` and `SPOTIFY_CLIENT_SECRET` as environment variables.
 
-`gradle jvmTest` and `gradle testDebugUnitTest`
+To additionally run **all** private (client) endpoint tests, you need a valid Spotify application, redirect uri, and token string. 
+The additional environment variables you will need to add are `SPOTIFY_REDIRECT_URI` and `SPOTIFY_TOKEN_STRING`.
 
-Note: You must have `SPOTIFY_CLIENT_ID` and `SPOTIFY_CLIENT_SECRET` as environment variables.
+Some tests may fail if you do not allow access to all required scopes. To mitigate this, you can individually grant
+each scope or use the following code snippet to print out the Spotify token string (given a generated authorization code). 
+However, you can painlessly generate a valid token by using the [spotify-web-api-token-helper](https://github.com/adamint/spotify-web-api-token-helper) 
+library.
 
-To run **all** tests, you need a valid Spotify application, redirect uri, and token string. use:
 
-`gradle jvmTest` and `gradle testDebugUnitTest`
+To run tests, run `gradle check`
 
-Note: In addition to `SPOTIFY_CLIENT_ID` and `SPOTIFY_CLIENT_SECRET`, you also must have the following environment 
-variables set up: `SPOTIFY_REDIRECT_URI` and `SPOTIFY_TOKEN_STRING`
-
-Some tests may fail if you do not allow access to all required scopes. To mitigate this, you can individually grant 
-each scope or use the following code snippet to print out the Spotify token string (given a generated authorization code)
 
 To build the maven artifact locally, you will need to follow these steps:
 - Create `gradle.properties` if it doesn't exist already.
-- Follow [this guide](https://gist.github.com/phit/bd3c6d156a2fa5f3b1bc15fa94b3256c). Instead of `.gpg` extension, use `.kbx` for your secring.
+- Follow [this guide](https://gist.github.com/phit/bd3c6d156a2fa5f3b1bc15fa94b3256c). Instead of `.gpg` extension, use `.kbx` for your secring.
+- Run `gradle publishToMavenLocal`
+
+You can use this artifact to test locally by adding the `mavenLocal()` repository in any local gradle project.
+
+To build docs, run `gradle dokkaHtml`. They will be located under the docs directory in the repostiory root, and 
+are ignored. This is how we generate release docs.