Fixed typos across fission repo (#1832)

Co-authored-by: Vishal <vishal-biyani@users.noreply.github.com>

Documentation/wip/testing-proposal.md

@@ -9,7 +9,7 @@ Most of current integration tests are CLI driven. Fission CLI is used to test ex
 This section only explains the problems/best practices without going into tooling and language used for implementation.
 ### Separating the test & data
 
-Seperating the tests from test data has two aspects - one is separation of concerns and second is scaling the tests without touching the test logic. The test data is a simple data structure which holds all information and test can take data and execute the logic.
+Separating the tests from test data has two aspects - one is separation of concerns and second is scaling the tests without touching the test logic. The test data is a simple data structure which holds all information and test can take data and execute the logic.
 
 As an example today we test "Hello world" for nodejs environment with a simple hello.js like this:
 
@@ -36,7 +36,7 @@ And feed it with a dictionary which has all possible combination of tests:
     node: {"fission/node-env", "test/hello.js", "/hellonode"},
     python: {"fission/python-env", "test/hello.py", "/hellopy"},
     golang: {"fission/go-env", "test/hello.go", "/hellogo"},
-    binray: {"fission/binary-env", "test/hello.sh", "/hellobinary"},
+    binary: {"fission/binary-env", "test/hello.sh", "/hellobinary"},
 }
 
 ```
@@ -63,7 +63,7 @@ The ability to have clean and separate before and after blocks, apart from separ
 - Running a suite of tests for same setup (See tagging for suite of tests)
 ### Tagging tests & running a selection
 
-Over a period of time as tests grow, there will be unit, smkoe, integration, performance, soak tests and so on. Ability to run a perticular test suite only or a combination of them makes it easy to run for specific purpose. 
+Over a period of time as tests grow, there will be unit, smoke, integration, performance, soak tests and so on. Ability to run a particular test suite only or a combination of them makes it easy to run for specific purpose. 
 ### Measuring test times
 
 [Good to have, not a must] Measuring time for tests and reporting somewhere helps over time to monitor trends. Although this job is better done by performance/benchmark tests so it is not a strict requirement
@@ -74,7 +74,7 @@ It would be good to have cleaner/relevant logging as part of build & test. For e
 
 It would be good to be able to run tests in parallel.
 
-## Evalutaing the tools/alternatives
+## Evaluating the tools/alternatives
 ### BATS
 
 Bash Automated Testing System is like a enhanced version of bash with support for @test tags and before and after steps & ability to skip tests etc. While it enhances the bash to certain extent, the overall improvement is only marginal.
@@ -111,7 +111,7 @@ https://golang.org/pkg/os/exec
 
 ### Using CLI package
 
-Currently we build a CLI and then execute the tests. The tests basically call one of functions from CLI package. If we decide to use a go lang based framework, then we can import the CLI package and then call those functions  by providing them context. This is as good as calling the Fission from CLI, with added benefit of programmibility of Go langugage.
+Currently we build a CLI and then execute the tests. The tests basically call one of functions from CLI package. If we decide to use a go lang based framework, then we can import the CLI package and then call those functions  by providing them context. This is as good as calling the Fission from CLI, with added benefit of programmability of Go language.
 
 ```
 func TestSomething(t *testing.T) {
@@ -135,7 +135,7 @@ Ginkgo is a BDD framework which works with Gomega matcher library. I will state
 From Ginkgo:
 
 - Global `BeforeSuite` and after `AfterSuite` can be used to have global setup and tear down phases
-- For tests `BeforeEach` and `AfterEach` and more such varients to do before and after test tasks.
+- For tests `BeforeEach` and `AfterEach` and more such variants to do before and after test tasks.
 
 From Gomega:
 
@@ -180,7 +180,7 @@ Eventually(session.Out).Should(gbytes.Say("hello [A-Za-z], world"))
 ```
 There are many more matchers which cane be found here: http://onsi.github.io/gomega/#provided-matchers 
 
-- We can build custom mathers in Go language for reusable logic.
+- We can build custom matchers in Go language for reusable logic.
 
 #### Links
 Ginkgo: http://onsi.github.io/ginkgo/
@@ -199,11 +199,11 @@ Based on the discussion with team, here are current thoughts and next action ite
 - How will migration of tests happen over time:
   - Aim is to keep existing tests around so that enough validation is in place
   - May be migrate one test at a time
-  - How much of current setup etc. will move into framework? For example it is clear that helm commands should be part of test framework as part of setup/teardown. But other sections may or may not be. A RCA needs to be done to analyze and come up with clear demarkation.
+  - How much of current setup etc. will move into framework? For example it is clear that helm commands should be part of test framework as part of setup/teardown. But other sections may or may not be. A RCA needs to be done to analyze and come up with clear demarcation.
 
 ## References
 
 - EngineYard uses BATS: https://www.engineyard.com/blog/bats-test-command-line-tools
 - AWS CLI Tests, written in Python (CLI itself is also in Python): https://github.com/aws/aws-cli/tree/develop/tests
 - Kubernetes uses Ginkgo and Gomega extensively: https://github.com/kubernetes/kubernetes/search?l=Go&q=onsi&type=
-- Hashicorp's Mitchell's talk on Advanced testing with go talks about some good patterns to use: https://www.youtube.com/watch?v=8hQG7QlcLBk 
+- Hashicorp's Mitchell's talk on Advanced testing with go talks about some good patterns to use: https://www.youtube.com/watch?v=8hQG7QlcLBk