From 7a40be161e4780b13cfa9c4bdc5d780d12c1827e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Hugo=20Bara=C3=BAna?= Date: Fri, 15 Jan 2016 11:48:09 -0200 Subject: [PATCH] Add a missing word --- getting-started/mix-otp/docs-tests-and-with.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/getting-started/mix-otp/docs-tests-and-with.markdown b/getting-started/mix-otp/docs-tests-and-with.markdown index cfcb2833c..0a8e87c28 100644 --- a/getting-started/mix-otp/docs-tests-and-with.markdown +++ b/getting-started/mix-otp/docs-tests-and-with.markdown @@ -361,7 +361,7 @@ However, it comes with the downside that our APIs become increasingly large in o The alternative is to write integration tests that will rely on the global server names to exercise the whole stack, from the TCP server to the bucket. The downside of integration tests is that they can be much slower than unit tests, and as such they must be used more sparingly. For example, we should not use integration tests to test an edge case in our command parsing implementation. -Since we have used unit tests so far, this time we will take the other road and write an integration test. The integration test will have a TCP client that sends commands to our server and we will assert that we are getting the desired responses. +Since we have only used unit tests so far, this time we will take the other road and write an integration test. The integration test will have a TCP client that sends commands to our server and we will assert that we are getting the desired responses. Let's implement our integration test in `test/kv_server_test.exs` as shown below: