Commits

Anonymous committed 8878c73

fixed typos

Comments (0)

Files changed (2)

_posts/2013-06-19-i_did_missbehave.md

 kinds of functions. We are in the fortunate position to be able to determine the correctness of a referentially transparent function just by looking
 at the arguments and the return value of the function. Indirect outputs would normally be side-effects, which don't exist in pure functions.
 
-That doesn't mean that scheme programs don't have side-effects, but they are rare and general discouraged.
+That doesn't mean that scheme programs don't have side-effects, but they are rare and generally discouraged.
 That again means, that I have provided a library that eases the testing/development of a small fraction of the code that you typically produce in scheme.
 That's not very useful, is it? So the bad idea here was:
 
 ~~~
 
 As I pointed out earlier, this can be useful in some situations, but those are rare.
-There is an additional problem, which is not so important for the client programmer, but still a reason I don't like that feature, is the implementation of
-that mechanism.
+There is an additional problem, which is not so important for the client programmer, but still a reason I don't like that feature; it's the implementation of that mechanism.
 
 <strong>Admission:</strong> It is implemented using a lot of mutation.
 
 #### 5) The runner
 
 This is something that turned out to complicate things. The library comes with an executable that is used to run missbehave tests. This means that
-you can not just run the test file itself using csi. That also means that you can't compile your test file which also means you can not use of FFI calls.
+you can not just run the test file itself using csi. That also means that you can't compile your test file which also means you can not use FFI calls.
 Also the chicken CI expects the tests to work in a certain way and without going through some hoops it was not possible to run missbehave in the
 context of [salmonella](http://tests.call-cc.org/). I added a way to do that later, as the following example shows:
 

_posts/2014-04-11-testing_your_chicken_code.md

 -- done testing stack --------------------------------------------------------
 </pre>
 
-As you can see the test output indicates that something went wrong. There red **ERROR** clearly indicates this. This is test's way to tell us that a condition has been signaled.
+As you can see the test output indicates that something went wrong. The red **ERROR** clearly indicates this. This is test's way to tell us that a condition has been signaled.
 The text following it shows the details, that make things clearer. It tells us that
-we attempted to use procedure that doesn't actually exist. This makes perfect sense since we didn't write any code yet. That's easy enough to mitigate.
+we attempted to use a procedure that doesn't actually exist. This makes perfect sense since we didn't write any code yet. That's easy enough to mitigate.
 
 ~~~ clojure
  (define-record-type stack (create-stack elements) stack? (elements stack-elements stack-elements-set!))
  (test-exit)
 ~~~
 
-You'll notice that I not only added a new test for **stack-push!** but also introduced the a now form: **(test-group)**. This form allows you to group related tests into a named context. Every group runs the tests it contains and finishes them with a status report, that tells you how many of the tests have failed and haw many have passed. I've added the group "stack-push!" that will hold all tests that are needed to cover the stack-push! procedure. While we're at it let's also create a group for make-stack. The test file now looks like this:
+You'll notice that I not only added a new test for **stack-push!** but also introduced the a new form: **(test-group)**. This form allows you to group related tests into a named context. Every group runs the tests it contains and finishes them with a status report, that tells you how many of the tests have failed and haw many have passed. I've added the group "stack-push!" that will hold all tests that are needed to cover the stack-push! procedure. While we're at it let's also create a group for make-stack. The test file now looks like this:
 
 ~~~clojure
  (use test)
 TEST_FILTER="empty stack is an error" csi -s run.scm
 </pre>
 
-This will only run the tests which include the given text in their description. The filter can actually be a regular expression, so it is much more versatile than it appears at first. There is also the variable TEST_GROUP_FILTER which allows you to run test-groups that match the filter. However in the current implementation of test, it is not to be possible to filter groups within other groups. So setting TEST_GROUP_FILTER="stack-top" doesn't currently work. It will not run any tests since the filter doesn't match the surrounding group "stack". It would be a nice addition though.
+This will only run the tests which include the given text in their description. The filter can actually be a regular expression, so it is much more versatile than it appears at first. There is also the variable TEST_GROUP_FILTER which allows you to run test-groups that match the filter. However in the current implementation of test, it is not possible to filter groups within other groups. So setting TEST_GROUP_FILTER="stack-top" doesn't currently work. It will not run any tests since the filter doesn't match the surrounding group "stack". It would be a nice addition though.
 
 The output with the filter expression looks like this:
 
 **Please pay close attention to the output.** The test passes!
 How can that be? We didn't even implement the part of the code which signals an error in the case of an empty stack.
 This is a good example of why it is good practice to write your tests **before** your code. If we had written the tests after the code, we would've never noticed that the tests succeed even without the proper implementation, which pretty much renders these tests useless. The test passes already because it is an error to take the **car** of the empty list. Obviously just checking, that an error occurred is not enough. We should verify, that a particular error has been raised. The test library doesn't provide a procedure or macro that does this, which means we have to come up with our own. We need a way to tell if and which condition has been signaled in a given expression. For this purpose we'll add a little helper to the very top
-of the test file and update the tests to use that little helper.
+of the test file and update the tests to use it.
 
 ~~~ clojure
  (use test)
 ### Bells and whistles of the test egg
 
 The test egg is very configurable. It gives you a knob for almost every aspect of it. I often found myself wanting features from
-test when I realize that it is already there. Test's author **Alex Shinn** did a very good job.
+test when I realized that they are already there. Test's author **Alex Shinn** did a very good job.
 
 There are a few parameters that you want to be aware of.
 
 ### Random testing with test-generative
 
 What we have done so far was thinking about which properties of our code we want to test and then
-creating inputs and validations than encode these properties. This is the somewhat classic approach that works really well and should be the foundation of your test suite. However there is another way to do your testing. It involves thinking about invariants of your procedures. Invariants are properties of your code that are always true. For example we can assert that for every non-empty list, taking the cdr of that list produces a list that is smaller than the original list.
+creating inputs and validations which encode these properties. This is the somewhat classic approach that works really well and should be the foundation of your test suite. However there is another way to do your testing. It involves thinking about invariants of your procedures. Invariants are properties of your code that are always true. For example we can assert that for every non-empty list, taking the cdr of that list produces a list that is smaller than the original list.
 
 ~~~clojure
  (let ((ls (list 1 2 3)))
      (< (length (cdr ls)) ls)))
 ~~~
 
-The **(test-assert)** form make invariants explicit. Once you have your invariants you can feed
+The **(test-assert)** form makes invariants explicit. Once you have your invariants you can feed
 data to your procedures and run them to see if they hold. Thinking of data that can be fed
 into procedures can be a tedious task. Wouldn't it be nice to have a way to generate the data
-and just concentrate on your invariants. There is a little library [test-generative](https://wiki.call-cc.org/eggref/4/test-generative) that allows you to do this. It extends the test egg, so that you can use generated data in order to find an application that violates some invariant. This style of testing is quite common in the haskell world. The most famous implementation of this approach is the [quick-check library](http://hackage.haskell.org/package/QuickCheck).
+and just concentrate on your invariants? There is a little library [test-generative](https://wiki.call-cc.org/eggref/4/test-generative) that allows you to do this. It extends the test egg, so that you can use generated data in order to find an application that violates some invariant. This style of testing is quite common in the haskell world. The most famous implementation of this approach is the [quick-check library](http://hackage.haskell.org/package/QuickCheck).
 
 #### Eliminating the programmer
 
 ~~~clojure
  (use test test-generative)
 
- (test-begin "random testing")
+ (test-begin "random-testing")
 
  (test-generative ((number (lambda () (random 10000))))
    (test-assert (negative? (* -1 number))))
 ~~~
 
 We've added a faster version of palindrome? and added the tests that are needed to signify the invariant. Mind the generator that now not only generates palindromes but also
-strings that are likely to not be a palindrome. For all these inputs we want fast-palindrome? to deliver the same result as palindrome?. The output indeed shows that they do. I'll leave it
+strings that are likely to not be a palindrome. For all these inputs we want fast-palindrome? to deliver the same result as palindrome? The output indeed shows that they do. I'll leave it
 out though as it is nothing new.
 
-Often times you will test against some procedure, that has already been defined by someone else and that you put great trust into. For example let's suppose we want to write a faster multiplication procedure that attempts to optimize by adding a fast path in case on of the arguments is 0.
+Often times you will test against some procedure, that has already been defined by someone else and that you put great trust into. For example let's suppose we want to write a faster multiplication procedure that attempts to optimize by adding a fast path in case one of the arguments is 0.
 
 ~~~clojure
 (define (fast-* x y)
   <img src="/assets/images/posts/testing_chicken/run-tests-w-failures_thumb.png">
 </a>
 
-The first failing tests has been selected and the line it occurs in has been highlighted.
+The first failing test has been selected and the line it occurs in has been highlighted.
 You can jump straight to the **n**ext failing test by hitting **n**.
 Likewise you can hit **p** to jump to the **p**revious failing test. Lastly you can hit
 **l** to jump to the last failing test.
 #### More possibilities to run tests
 
 Beside running the full test-suite, you can also apply a filter and run only those tests that
-match the it. Let's suppose that we only want to run the tests that contain the text "top-most". In reality you might want to mark your tests specially, as I have already described in the best practices section. To run tests filtered you can type **C-t f** which will ask you for the filter to apply. It looks like this:
+match it. Let's suppose that we only want to run the tests that contain the text "top-most". In reality you might want to mark your tests specially, as I have already described in the best practices section. To run tests filtered you can type **C-t f** which will ask you for the filter to apply. It looks like this:
 
 <a href="/assets/images/posts/testing_chicken/run-tests-w-filter.png">
   <img src="/assets/images/posts/testing_chicken/run-tests-w-filter_thumb.png">