1. 19 Dec, 2012 1 commit
  2. 18 Dec, 2012 1 commit
  3. 17 Dec, 2012 1 commit
  4. 06 Dec, 2012 1 commit
  5. 03 Dec, 2012 1 commit
  6. 30 Nov, 2012 1 commit
  7. 21 Nov, 2012 1 commit
  8. 20 Nov, 2012 1 commit
  9. 16 Nov, 2012 1 commit
  10. 12 Nov, 2012 1 commit
  11. 22 Oct, 2012 2 commits
    • Iustin Pop's avatar
      Improve message for (==?) operator · 41eb900e
      Iustin Pop authored
      
      
      After seeing how nice HUnit formats the error message on failed
      'assertEqual', I think we can do better with ==?. Currently it says
      (on one line): "Expected equality, but 1 /= 2".
      
      This patch changes the code to format it similar to HUnit:
      
        Expected equality, but got mismatch
        expected: 1
         but got: 2
      
      (on three lines). This makes it more clear what is the expected and
      what is the wrong value.
      
      A few tests have been modified to ensure that the expected value is
      the second argument to ==?. This is different than HUnit, but makes
      more sense in the operator version (I think).
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarHelga Velroyen <helgav@google.com>
      41eb900e
    • Helga Velroyen's avatar
      Annotated inequality operator for unit test properties · dddb2bc9
      Helga Velroyen authored
      
      
      This includes:
       * The operator (/=?), which checks for inequality and prints
         an error message if it encounters equality. (Basically the
         negation of the (==?) operator).
       * Application of this operator in the test property
         prop_addPri_NoN1Fail.
      Signed-off-by: default avatarHelga Velroyen <helgav@google.com>
      Reviewed-by: default avatarIustin Pop <iustin@google.com>
      dddb2bc9
  12. 17 Oct, 2012 1 commit
    • Iustin Pop's avatar
      Generalise the Result type · 93be1ced
      Iustin Pop authored
      
      
      Currently, our error monad—Result—has a plain string error type. This
      is not good, as we don't have structured errors, we can't pass back
      proper error information to Python code, etc.
      
      To solve this, we generalise this type as 'GenericResult a', and make
      Result an alias to 'GenericResult String' for compatibility with the
      old code. New error hierarchies will be introduced as different
      types. Furthermore, we generalise our helper functions too, so that
      they can work on any 'GeneralInstance a' type, not only Result.
      
      There are two small drawbacks to this generalisation. First, a Monad
      instance requires (at least for the way we use it) a 'fail :: String
      -> m a' instance, so we need to be able to build an 'a' value from a
      string; therefore, we can implement the Monad instance only for a
      newly-introduced typeclass, 'FromString', which requires the needed
      conversion function. Second, due to the fact that 'String' is a type
      alias (for [Char]) instead of an actual type, we need to enable the
      FlexibleInstances language pragma; as far as I know, this has no
      significant drawbacks.
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarMichael Hanselmann <hansmi@google.com>
      93be1ced
  13. 05 Sep, 2012 4 commits
    • Iustin Pop's avatar
      Further hlint fixes · 5b11f8db
      Iustin Pop authored
      Commit 2cdaf225, “Re-enable standard hlint warnings”, got it almost
      right. The only problem is that (confusingly) the default set of hints
      is not in HLint.Default, but in HLint.HLint (it includes Default and
      some built-ins).
      
      After changing the lint file to correctly include the defaults, we had
      another 128 suggestions:
      
        - Error: Eta reduce (2)
        - Error: Redundant bracket (4)
        - Error: Redundant do (17)
        - Error: Redundant lambda (7)
        - Error: Redundant return (1)
        - Warning: Avoid lambda (2)
        - Warning: Redundant $ (42)
        - Warning: Redundant bracket (35)
        - Warning: Use : (1)
        - Warning: Use String (4)
        - Warning: Use camelCase (10)
        - Warning: Use section (3)
      
      which are fixed by the current patch. Note that the 10 "Use camelCase"
      were all due to hlint not “knowing” the idiom of ‘case_’ (it does for
      ‘prop_’), for which I filled
      http://code.google.com/p/ndmitchell/issues/detail?id=558
      
      .
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarRené Nussbaumer <rn@google.com>
      5b11f8db
    • Iustin Pop's avatar
      Add some unittests for node queries · b9bdc10e
      Iustin Pop authored
      
      
      These new tests check that:
      
      - no known fields return unknown
      - any unknown field returns unknown
      - the type of the fields is consistent between the getters and the
        field definition
      - the length of each result row corresponds with the number of fields
        queried, and the length of the field definitions returned
      - the length of the rows corresponds to the number of nodes
      - querying fields on empty fields returns all fields
      
      Finally this patch found a bug, in that the pinst_list/sinst_list
      fields were declared as QFTNumber (copy-paste error from
      pinst_cnt/sinst_cnt), yay!
      
      I also changed genEmptyCluster to ensure that it generates unique node
      names, so that the number of result rows is consistent with what we
      requested, and switched ResultEntry from a normal constructor to
      record syntax, so that we can extract the fields without having to use
      pattern matching.
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarRené Nussbaumer <rn@google.com>
      b9bdc10e
    • Iustin Pop's avatar
      Add a small 'passTest' helper · 2e0bb81d
      Iustin Pop authored
      
      
      This is symmetric to failTest, and allows us to use it in cases where
      we need to return a property.
      
      While replacing 'property True' with it, I saw a case where we can
      simplify the use and thus reworked that check.
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarRené Nussbaumer <rn@google.com>
      2e0bb81d
    • Iustin Pop's avatar
      Add a test helper for simple JSON serialisation testing · 63b068c1
      Iustin Pop authored
      
      
      While adding yet another JSON serialisation test, I realised that this
      can be trivially abstracted; hence this patch, replacing both simple
      versions (readJSON . showJSON == id) and the standard version (with
      different error messages) across the tests with a single function
      call.
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarRené Nussbaumer <rn@google.com>
      63b068c1
  14. 04 Sep, 2012 4 commits