6 ms·

It's strange to me that we continue to make languages that force us to make certain architectural choices to help facilitate testing.

by sbov 9y ago

cbanek 9y ago
Indeed. It's almost as if testing should be built into the language itself. (I'm always a big fan of including self-test code in projects)
- vincnetas 9y ago
  What are the languages that have testing not as afterthought?
  - pacaro 9y ago
    This depends on how you think of things. Some languages (Eiffel?) have pre- and post-conditions, which do some of this job. Much of the boilerplate testing done for dynamic languages is done by the compiler for static languages. The borrow checker in Rust is doing the work that a test suite and/or static analysis tool would be doing for C/C++
  - realusername 9y ago
    Definitely Ruby in general, testing is a core of the language culture.
    - pkroll 9y ago
      That doesn't mean testing isn't an afterthought in Ruby, the language. It means the culture built up a defense against writing buggy code.
    - tracker1 9y ago
      I think that's the nature of a dynamic/scripted language... it's just easier to handle in Ruby and JS than many other languages.
- thinkloop 9y ago
  > testing should be built into the language itself I wonder what that would look like...
  - saosebastiao 9y ago
    Rust has simple unit testing built into the language. And in Ada/Spark, tests can be a first class verification tool, alongside formal verification. We should go a lot further though. IMO, a unit that does not pass a spec/test should cause a compile time error. Testing systems should facilitate and converge with formal verification. Where possible, property based testing should be used and encouraged. And debugger tools should be able to hone in on areas where the result diverges from expectations.
    - cbanek 9y ago
      ^ This. And another example of something I'd want checked by the language is exception throwing / handling. It's another one of those places where code coverage won't help you unless you already know what you're looking for. Languages are getting better about it, but in general, handling errors is hard.
    - tjalfi 9y ago
      Force.com doesn't allow you to deploy code to production unless at least 75% of the statements are executed[0]. I wish my employer had a similar requirement. [0] https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_testing_best_practices.htm https://developer.salesforce.com/docs/atlas.en-us.apexcode.m...
    - chriswarbo 9y ago
      > IMO, a unit that does not pass a spec/test should cause a compile time error. We can achieve this in dependently-typed languages like Idris. First we define a datatype 'Equal x y', which will represent the proposition that expression 'x' is equal to expression 'y': data Equal x y where Refl : (x : _) -> Equal x x There are two things to note: - There is only one way to construct a value of type `Equal x y`, which is to use the constructor we've called `Refl`. - `Refl` only takes one argument, `x` (of arbitrary type `_`), and it only constructs values of type `Equal x x`. This is called "reflexivity", thus the name `Refl`. Hence if we use the type `Expr x y` anywhere in our program, there is only one possible value we can provide that might typecheck (`Refl x`), and that will only typecheck if `Expr x x` unifies with `Expr x y`, which will only happen if `x` and `y` are the same thing; i.e. if they are equal. Thus the name `Equal`. This `Equal` type comes in the standard library of all dependently typed languages, and is widely used. To use it for testing we just need to write a test, e.g. `myTest`, which returns some value indicating pass/fail, e.g. a `Boolean`. Then we can add the following to our program: myTestPasses : Equal myTest True myTestPasses = Refl myTest This will only type-check if `Equal myTest myTest` (the type of `Refl myTest`) unifies with `Equal myTest True`, which will only be the case if `myTest` evaluates to `True`.
- WalterBright 9y ago
  And it is built in in D: http://dlang.org/spec/unittest.html http://dlang.org/spec/unittest.html It's been very effective at improving the overall quality of the code. And because of CTFE (Compile Time Function Execution) and static assert, many code correctness tests can even be run at compile time.
- V-2 9y ago
  http://cobra-language.com/ http://cobra-language.com/ had it.
pjmlp 9y ago
We have it since Eiffel and Common Lisp, but not all mainstream languages were keen on adopting design by contract. On .NET it is a plain library, which requires the VS Ultimate editions to be useful and on Java it was mostly third party libraries. C# design team is considering adding proper support as language feature, but it seems to be a very far away feature still. C++20 might get contracts, but C++17 just got ratified, so who knows. D, Ada 2012 and SPARK do already support contracts.

It's strange to me that we continue to make languages that force us to make certain architectural choices to help facilitate testing.

by sbov 9y ago

It's strange to me that we continue to make languages that force us to make certain architectural choices to help facilitate testing.

cbanek 9y ago

Indeed. It's almost as if testing should be built into the language itself. (I'm always a big fan of including self-test code in projects)

vincnetas 9y ago
What are the languages that have testing not as afterthought?
- pacaro 9y ago
  This depends on how you think of things. Some languages (Eiffel?) have pre- and post-conditions, which do some of this job. Much of the boilerplate testing done for dynamic languages is done by the compiler for static languages. The borrow checker in Rust is doing the work that a test suite and/or static analysis tool would be doing for C/C++
- realusername 9y ago
  Definitely Ruby in general, testing is a core of the language culture.
  - pkroll 9y ago
    That doesn't mean testing isn't an afterthought in Ruby, the language. It means the culture built up a defense against writing buggy code.
  - tracker1 9y ago
    I think that's the nature of a dynamic/scripted language... it's just easier to handle in Ruby and JS than many other languages.
thinkloop 9y ago
> testing should be built into the language itself I wonder what that would look like...
- saosebastiao 9y ago
  Rust has simple unit testing built into the language. And in Ada/Spark, tests can be a first class verification tool, alongside formal verification. We should go a lot further though. IMO, a unit that does not pass a spec/test should cause a compile time error. Testing systems should facilitate and converge with formal verification. Where possible, property based testing should be used and encouraged. And debugger tools should be able to hone in on areas where the result diverges from expectations.
  - cbanek 9y ago
    ^ This. And another example of something I'd want checked by the language is exception throwing / handling. It's another one of those places where code coverage won't help you unless you already know what you're looking for. Languages are getting better about it, but in general, handling errors is hard.
  - tjalfi 9y ago
    Force.com doesn't allow you to deploy code to production unless at least 75% of the statements are executed[0]. I wish my employer had a similar requirement. [0] https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_testing_best_practices.htm https://developer.salesforce.com/docs/atlas.en-us.apexcode.m...
  - chriswarbo 9y ago
    > IMO, a unit that does not pass a spec/test should cause a compile time error. We can achieve this in dependently-typed languages like Idris. First we define a datatype 'Equal x y', which will represent the proposition that expression 'x' is equal to expression 'y': data Equal x y where Refl : (x : _) -> Equal x x There are two things to note: - There is only one way to construct a value of type `Equal x y`, which is to use the constructor we've called `Refl`. - `Refl` only takes one argument, `x` (of arbitrary type `_`), and it only constructs values of type `Equal x x`. This is called "reflexivity", thus the name `Refl`. Hence if we use the type `Expr x y` anywhere in our program, there is only one possible value we can provide that might typecheck (`Refl x`), and that will only typecheck if `Expr x x` unifies with `Expr x y`, which will only happen if `x` and `y` are the same thing; i.e. if they are equal. Thus the name `Equal`. This `Equal` type comes in the standard library of all dependently typed languages, and is widely used. To use it for testing we just need to write a test, e.g. `myTest`, which returns some value indicating pass/fail, e.g. a `Boolean`. Then we can add the following to our program: myTestPasses : Equal myTest True myTestPasses = Refl myTest This will only type-check if `Equal myTest myTest` (the type of `Refl myTest`) unifies with `Equal myTest True`, which will only be the case if `myTest` evaluates to `True`.
WalterBright 9y ago
And it is built in in D: http://dlang.org/spec/unittest.html http://dlang.org/spec/unittest.html It's been very effective at improving the overall quality of the code. And because of CTFE (Compile Time Function Execution) and static assert, many code correctness tests can even be run at compile time.
V-2 9y ago
http://cobra-language.com/ http://cobra-language.com/ had it.

pjmlp 9y ago

We have it since Eiffel and Common Lisp, but not all mainstream languages were keen on adopting design by contract. On .NET it is a plain library, which requires the VS Ultimate editions to be useful and on Java it was mostly third party libraries. C# design team is considering adding proper support as language feature, but it seems to be a very far away feature still. C++20 might get contracts, but C++17 just got ratified, so who knows. D, Ada 2012 and SPARK do already support contracts.