Re: [racket-users] test submodules vs tests in separate file
And apologies for this completely wrong remark! On Fri, May 22, 2015 at 7:19 AM, Robby Findler ro...@eecs.northwestern.edu wrote: Contracts mediate boundaries between parts of your program and sometimes tests should go across the boundary (to help test the contracts) and sometimes they should go inside (to test internal functions). You have to pick one or the other with a given test module tho. Robby On Friday, May 22, 2015, Atticus attic...@posteo.org wrote: That's good to know. That means my previous conclusion is wrong and I'm not forced to use define/contract when using test submodules. Robby Findler ro...@eecs.northwestern.edu writes: For that kind of situation, you should consider writing your test submodule like this: #lang racket (define (add1 x y) (integer? integer? . - . integer?) (+ x y)) (provide (contract-out [add1 (integer? integer? . - . integer?)])) (module* test racket (require (submod ..)) (add1 #f #f)) Robby On Thu, May 21, 2015 at 10:58 PM, Matthew Butterick m...@mbtype.com wrote: Are there any advantages/disadvantages of using test submodules vs separate test files? Or is it just a matter of personal preference? It looks like that test submodules are more convenient and flexible but I observed that test submodules increase the start up time of racket scripts. If you're using contracts, you want your tests to cross the contract boundaries. If you attach your contracts at the module boundary (a common practice), then submodule tests will not trigger the contracts. (Example below.) So putting these tests in a separate file is the better option. ; #lang racket (define/contract (add1 x y) (integer? integer? . - . integer?) (+ x y)) (provide (contract-out [add2 (integer? integer? . - . integer?)])) (define (add2 x y) (+ x y)) (module+ test (require rackunit) (check-exn exn:fail? (λ _ (add1 20.5 21.5))) (check-equal? (add2 20.5 21.5) 42.0)) ; surprise! ; -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] test submodules vs tests in separate file
; #lang racket (define/contract (add1 x y) (integer? integer? . - . integer?) (+ x y)) (provide (contract-out [add2 (integer? integer? . - . integer?)])) (define (add2 x y) (+ x y)) (module+ test (require rackunit) (check-exn exn:fail? (λ _ (add1 20.5 21.5))) (check-equal? (add2 20.5 21.5) 42.0)) ; surprise! ; That is an interesting example and an important hint, thank you Matthew. Looking at the documentation it's interesting that your example seems to work within submodules, in contrast to your example with contracts at the module boundary. Your modified example: (module+ contract-test (define/contract (add1 x y) (integer? integer? . - . integer?) (+ x y)) (provide (contract-out [add2 (integer? integer? . - . integer?)])) (define (add2 x y) (+ x y))) (module+ test (require rackunit) (require (submod .. contract-test)) (check-exn exn:fail? (λ _ (add1 20.5 21.5))) (check-equal? (add2 20.5 21.5) 42.0)) $ raco test contract-test ... add2: contract violation ... Imho it would be nice if there was a small hint in the documentation about that case, perhaps there is and I didn't see it? Matthew Butterick m...@mbtype.com writes: Are there any advantages/disadvantages of using test submodules vs separate test files? Or is it just a matter of personal preference? It looks like that test submodules are more convenient and flexible but I observed that test submodules increase the start up time of racket scripts. If you're using contracts, you want your tests to cross the contract boundaries. If you attach your contracts at the module boundary (a common practice), then submodule tests will not trigger the contracts. (Example below.) So putting these tests in a separate file is the better option. ; #lang racket (define/contract (add1 x y) (integer? integer? . - . integer?) (+ x y)) (provide (contract-out [add2 (integer? integer? . - . integer?)])) (define (add2 x y) (+ x y)) (module+ test (require rackunit) (check-exn exn:fail? (λ _ (add1 20.5 21.5))) (check-equal? (add2 20.5 21.5) 42.0)) ; surprise! ; -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] test submodules vs tests in separate file
For that kind of situation, you should consider writing your test submodule like this: #lang racket (define (add1 x y) (integer? integer? . - . integer?) (+ x y)) (provide (contract-out [add1 (integer? integer? . - . integer?)])) (module* test racket (require (submod ..)) (add1 #f #f)) Robby On Thu, May 21, 2015 at 10:58 PM, Matthew Butterick m...@mbtype.com wrote: Are there any advantages/disadvantages of using test submodules vs separate test files? Or is it just a matter of personal preference? It looks like that test submodules are more convenient and flexible but I observed that test submodules increase the start up time of racket scripts. If you're using contracts, you want your tests to cross the contract boundaries. If you attach your contracts at the module boundary (a common practice), then submodule tests will not trigger the contracts. (Example below.) So putting these tests in a separate file is the better option. ; #lang racket (define/contract (add1 x y) (integer? integer? . - . integer?) (+ x y)) (provide (contract-out [add2 (integer? integer? . - . integer?)])) (define (add2 x y) (+ x y)) (module+ test (require rackunit) (check-exn exn:fail? (λ _ (add1 20.5 21.5))) (check-equal? (add2 20.5 21.5) 42.0)) ; surprise! ; -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] test submodules vs tests in separate file
Yes, there is : http://docs.racket-lang.org/style/Units_of_Code.html?q=define%2Fcontract#%28part._.Contracts%29 Thank you for the link. The How to Program Racket Guide will be really helpful. But I must admit I'm a little confused. Looking at the *fahrenheit* example in the Guide: #lang racket (provide (contract-out ; convert a fahrenheit temperature to a celsius [fahrenheit-celsius (- number? number?)])) (define (fahrenheit-celsius f) (/ (* 5 (- f 32)) 9)) (module+ test (require rackunit) (check-equal? (fahrenheit-celsius -40) -40) (check-equal? (fahrenheit-celsius 32) 0) (check-equal? (fahrenheit-celsius 212) 100)) This example implies that the contracts are enforced in the test submodule (contrary to Matthews example) but modifing the example shows that this is not the case: (provide (contract-out ; convert a fahrenheit temperature to a celsius [fahrenheit-celsius (- integer? integer?)])) (define (fahrenheit-celsius f) (/ (* 5 (- f 32)) 9)) (module+ test (require rackunit) (check-equal? (fahrenheit-celsius -40) -40) (check-equal? (fahrenheit-celsius 32) 0) (check-equal? (fahrenheit-celsius 212.1) 100.06)) This is not very clear and confusing. If I would read the guide and I didn't know about Matthews example I would assume that the test in the modified example fails. My conclusion is: When using contracts with submodules use define/contract instead of (provide (contract-out ...)) black-box tests are always embedded in documentation so that if the documentation does not show errors, then the system is reasonably correct (for bugs that already found). source code can keep elegant, and leave all the dirty things to scribble. This is a really nice idea. Thanks for sharing. WarGrey Gyoudmon Ju juzhenli...@gmail.com writes: On Fri, May 22, 2015 at 5:41 PM, Atticus attic...@posteo.org wrote: Imho it would be nice if there was a small hint in the documentation about that case, perhaps there is and I didn't see it? Yes, there is : http://docs.racket-lang.org/style/Units_of_Code.html?q=define%2Fcontract#%28part._.Contracts%29 In practice, I design tests in a system level abstraction. black-box tests are always embedded in documentation so that if the documentation does not show errors, then the system is reasonably correct (for bugs that already found). source code can keep elegant, and leave all the dirty things to scribble. I almost do not write white-box tests since Racket and Typed Racket itself has already formal enough, moreover these tests or verifications can also be moved to documentation if needed. -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] test submodules vs tests in separate file
That's good to know. That means my previous conclusion is wrong and I'm not forced to use define/contract when using test submodules. Robby Findler ro...@eecs.northwestern.edu writes: For that kind of situation, you should consider writing your test submodule like this: #lang racket (define (add1 x y) (integer? integer? . - . integer?) (+ x y)) (provide (contract-out [add1 (integer? integer? . - . integer?)])) (module* test racket (require (submod ..)) (add1 #f #f)) Robby On Thu, May 21, 2015 at 10:58 PM, Matthew Butterick m...@mbtype.com wrote: Are there any advantages/disadvantages of using test submodules vs separate test files? Or is it just a matter of personal preference? It looks like that test submodules are more convenient and flexible but I observed that test submodules increase the start up time of racket scripts. If you're using contracts, you want your tests to cross the contract boundaries. If you attach your contracts at the module boundary (a common practice), then submodule tests will not trigger the contracts. (Example below.) So putting these tests in a separate file is the better option. ; #lang racket (define/contract (add1 x y) (integer? integer? . - . integer?) (+ x y)) (provide (contract-out [add2 (integer? integer? . - . integer?)])) (define (add2 x y) (+ x y)) (module+ test (require rackunit) (check-exn exn:fail? (λ _ (add1 20.5 21.5))) (check-equal? (add2 20.5 21.5) 42.0)) ; surprise! ; -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] test submodules vs tests in separate file
Contracts mediate boundaries between parts of your program and sometimes tests should go across the boundary (to help test the contracts) and sometimes they should go inside (to test internal functions). You have to pick one or the other with a given test module tho. Robby On Friday, May 22, 2015, Atticus attic...@posteo.org wrote: That's good to know. That means my previous conclusion is wrong and I'm not forced to use define/contract when using test submodules. Robby Findler ro...@eecs.northwestern.edu javascript:; writes: For that kind of situation, you should consider writing your test submodule like this: #lang racket (define (add1 x y) (integer? integer? . - . integer?) (+ x y)) (provide (contract-out [add1 (integer? integer? . - . integer?)])) (module* test racket (require (submod ..)) (add1 #f #f)) Robby On Thu, May 21, 2015 at 10:58 PM, Matthew Butterick m...@mbtype.com javascript:; wrote: Are there any advantages/disadvantages of using test submodules vs separate test files? Or is it just a matter of personal preference? It looks like that test submodules are more convenient and flexible but I observed that test submodules increase the start up time of racket scripts. If you're using contracts, you want your tests to cross the contract boundaries. If you attach your contracts at the module boundary (a common practice), then submodule tests will not trigger the contracts. (Example below.) So putting these tests in a separate file is the better option. ; #lang racket (define/contract (add1 x y) (integer? integer? . - . integer?) (+ x y)) (provide (contract-out [add2 (integer? integer? . - . integer?)])) (define (add2 x y) (+ x y)) (module+ test (require rackunit) (check-exn exn:fail? (λ _ (add1 20.5 21.5))) (check-equal? (add2 20.5 21.5) 42.0)) ; surprise! ; -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com javascript:;. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com javascript:;. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com javascript:;. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] test submodules vs tests in separate file
On Fri, May 22, 2015 at 5:41 PM, Atticus attic...@posteo.org wrote: Imho it would be nice if there was a small hint in the documentation about that case, perhaps there is and I didn't see it? Yes, there is : http://docs.racket-lang.org/style/Units_of_Code.html?q=define%2Fcontract#%28part._.Contracts%29 In practice, I design tests in a system level abstraction. black-box tests are always embedded in documentation so that if the documentation does not show errors, then the system is reasonably correct (for bugs that already found). source code can keep elegant, and leave all the dirty things to scribble. I almost do not write white-box tests since Racket and Typed Racket itself has already formal enough, moreover these tests or verifications can also be moved to documentation if needed. -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] test submodules vs tests in separate file
Has this been an oversight? Do we need two official test submodules? One from the inside, and one from without. -- Anthony Carrico -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] test submodules vs tests in separate file
You could always do something like (require (prefix-in contracted: (submod ..))) to get separate bindings for the versions contracted by contract-out. On May 22, 2015, at 11:37, Anthony Carrico acarr...@memebeam.org wrote: Has this been an oversight? Do we need two official test submodules? One from the inside, and one from without. -- Anthony Carrico -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] test submodules vs tests in separate file
Has this been an oversight? Do we need two official test submodules? One from the inside, and one from without. That’s a worthy point. I prefer to locate tests as close as possible to the code being tested. But the fact that 'raco test ...' and DrRacket only recognize a single submodule named 'test' means that internal external tests must be separated (because you can’t have two submodules with the same name). Perhaps it would be worthwhile for raco DrRacket to recognize not just 'test', but any submodule named 'test-*', so that multiple testing submodules can live together in peace and cooperation: #lang racket (define (add1 x y) (integer? integer? . - . integer?) (+ x y)) (provide (contract-out [add1 (integer? integer? . - . integer?)])) (module* test-external racket (require (submod ..)) (require rackunit) (check-exn exn:fail? (λ _ (add1 3 3 (module+ test-internal (require rackunit) (check-equal? (add1 4.5 4.5) 7.0)) On Fri, May 22, 2015 at 11:37 AM, Anthony Carrico acarr...@memebeam.org wrote: Has this been an oversight? Do we need two official test submodules? One from the inside, and one from without. -- Anthony Carrico -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] test submodules vs tests in separate file
If you want to have the contracts enforced in the test submodule, all you have to do is add (require (submod “..”)) to the submodule. You don’t need to use define/contract, and you don’t need to use module* instead of module+. You can just use #lang racket (provide (contract-out ; convert a fahrenheit temperature to a celsius [fahrenheit-celsius (- (and/c number? (=/c -459.67)) number?)])) (define (fahrenheit-celsius f) (/ (* 5 (- f 32)) 9)) (module+ test (require rackunit (submod ..)) ; the (submod ..) makes it enforce the contracts (check-equal? (fahrenheit-celsius -40) -40) (check-equal? (fahrenheit-celsius 32) 0) (check-equal? (fahrenheit-celsius 212) 100) ;; this checks that it raises a contract-error (check-exn exn:fail:contract? (λ () (fahrenheit-celsius -500 On May 22, 2015, at 7:58 AM, Atticus attic...@posteo.org wrote: Yes, there is : http://docs.racket-lang.org/style/Units_of_Code.html?q=define%2Fcontract#%28part._.Contracts%29 Thank you for the link. The How to Program Racket Guide will be really helpful. But I must admit I'm a little confused. Looking at the *fahrenheit* example in the Guide: #lang racket (provide (contract-out ; convert a fahrenheit temperature to a celsius [fahrenheit-celsius (- number? number?)])) (define (fahrenheit-celsius f) (/ (* 5 (- f 32)) 9)) (module+ test (require rackunit) (check-equal? (fahrenheit-celsius -40) -40) (check-equal? (fahrenheit-celsius 32) 0) (check-equal? (fahrenheit-celsius 212) 100)) This example implies that the contracts are enforced in the test submodule (contrary to Matthews example) but modifing the example shows that this is not the case: (provide (contract-out ; convert a fahrenheit temperature to a celsius [fahrenheit-celsius (- integer? integer?)])) (define (fahrenheit-celsius f) (/ (* 5 (- f 32)) 9)) (module+ test (require rackunit) (check-equal? (fahrenheit-celsius -40) -40) (check-equal? (fahrenheit-celsius 32) 0) (check-equal? (fahrenheit-celsius 212.1) 100.06)) This is not very clear and confusing. If I would read the guide and I didn't know about Matthews example I would assume that the test in the modified example fails. My conclusion is: When using contracts with submodules use define/contract instead of (provide (contract-out ...)) black-box tests are always embedded in documentation so that if the documentation does not show errors, then the system is reasonably correct (for bugs that already found). source code can keep elegant, and leave all the dirty things to scribble. This is a really nice idea. Thanks for sharing. WarGrey Gyoudmon Ju juzhenli...@gmail.com writes: On Fri, May 22, 2015 at 5:41 PM, Atticus attic...@posteo.org wrote: Imho it would be nice if there was a small hint in the documentation about that case, perhaps there is and I didn't see it? Yes, there is : http://docs.racket-lang.org/style/Units_of_Code.html?q=define%2Fcontract#%28part._.Contracts%29 In practice, I design tests in a system level abstraction. black-box tests are always embedded in documentation so that if the documentation does not show errors, then the system is reasonably correct (for bugs that already found). source code can keep elegant, and leave all the dirty things to scribble. I almost do not write white-box tests since Racket and Typed Racket itself has already formal enough, moreover these tests or verifications can also be moved to documentation if needed. -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] test submodules vs tests in separate file
DOn't forget $ raco test --submoulde matthew-s-tests On May 22, 2015, at 3:12 PM, Matthew Butterick m...@mbtype.com wrote: Has this been an oversight? Do we need two official test submodules? One from the inside, and one from without. That’s a worthy point. I prefer to locate tests as close as possible to the code being tested. But the fact that 'raco test ...' and DrRacket only recognize a single submodule named 'test' means that internal external tests must be separated (because you can’t have two submodules with the same name). Perhaps it would be worthwhile for raco DrRacket to recognize not just 'test', but any submodule named 'test-*', so that multiple testing submodules can live together in peace and cooperation: #lang racket (define (add1 x y) (integer? integer? . - . integer?) (+ x y)) (provide (contract-out [add1 (integer? integer? . - . integer?)])) (module* test-external racket (require (submod ..)) (require rackunit) (check-exn exn:fail? (λ _ (add1 3 3 (module+ test-internal (require rackunit) (check-equal? (add1 4.5 4.5) 7.0)) On Fri, May 22, 2015 at 11:37 AM, Anthony Carrico acarr...@memebeam.org wrote: Has this been an oversight? Do we need two official test submodules? One from the inside, and one from without. -- Anthony Carrico -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] test submodules vs tests in separate file
On May 22, 2015, at 8:19 AM, Robby Findler ro...@eecs.northwestern.edu wrote: Contracts mediate boundaries between parts of your program and sometimes tests should go across the boundary (to help test the contracts) and sometimes they should go inside (to test internal functions). You have to pick one or the other with a given test module tho. Wouldn’t just this: (module+ test (require (submod “..”)) ; tests here ) Allow both of those things? #lang racket (provide (contract-out ; convert a fahrenheit temperature to a celsius [fahrenheit-celsius (- (and/c number? (=/c -459.67)) number?)])) (define (fahrenheit-celsius f) (multiply-by-5/9 (- f 32))) (define (multiply-by-5/9 x) ; not provided (* 5/9 x)) (module+ test (require rackunit (submod ..)) ; the (submod ..) makes it enforce the contracts (check-equal? (fahrenheit-celsius -40) -40) (check-equal? (fahrenheit-celsius 32) 0) (check-equal? (fahrenheit-celsius 212) 100) ;; this checks that it raises a contract-error (check-exn exn:fail:contract? (λ () (fahrenheit-celsius -500))) ;; this checks the internal unprovided function (check-equal? (multiply-by-5/9 18) 10) ) -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] test submodules vs tests in separate file
Adding to the suggestions, you can write something like `test-internal` and `test-external` submodules plus (module+ test (require (submod .. test-internal) (submod .. test-external))) At Fri, 22 May 2015 15:23:33 -0400, Matthias Felleisen wrote: DOn't forget $ raco test --submoulde matthew-s-tests On May 22, 2015, at 3:12 PM, Matthew Butterick m...@mbtype.com wrote: Has this been an oversight? Do we need two official test submodules? One from the inside, and one from without. That’s a worthy point. I prefer to locate tests as close as possible to the code being tested. But the fact that 'raco test ...' and DrRacket only recognize a single submodule named 'test' means that internal external tests must be separated (because you can’t have two submodules with the same name). Perhaps it would be worthwhile for raco DrRacket to recognize not just 'test', but any submodule named 'test-*', so that multiple testing submodules can live together in peace and cooperation: #lang racket (define (add1 x y) (integer? integer? . - . integer?) (+ x y)) (provide (contract-out [add1 (integer? integer? . - . integer?)])) (module* test-external racket (require (submod ..)) (require rackunit) (check-exn exn:fail? (λ _ (add1 3 3 (module+ test-internal (require rackunit) (check-equal? (add1 4.5 4.5) 7.0)) On Fri, May 22, 2015 at 11:37 AM, Anthony Carrico acarr...@memebeam.org wrote: Has this been an oversight? Do we need two official test submodules? One from the inside, and one from without. -- Anthony Carrico -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] test submodules vs tests in separate file
Adding to the suggestions, you can write something like `test-internal` and `test-external` submodules plus (module+ test (require (submod .. test-internal) (submod .. test-external))) Enlightenment achieved At Fri, 22 May 2015 15:23:33 -0400, Matthias Felleisen wrote: DOn't forget $ raco test --submoulde matthew-s-tests On May 22, 2015, at 3:12 PM, Matthew Butterick m...@mbtype.com wrote: Has this been an oversight? Do we need two official test submodules? One from the inside, and one from without. That’s a worthy point. I prefer to locate tests as close as possible to the code being tested. But the fact that 'raco test ...' and DrRacket only recognize a single submodule named 'test' means that internal external tests must be separated (because you can’t have two submodules with the same name). Perhaps it would be worthwhile for raco DrRacket to recognize not just 'test', but any submodule named 'test-*', so that multiple testing submodules can live together in peace and cooperation: #lang racket (define (add1 x y) (integer? integer? . - . integer?) (+ x y)) (provide (contract-out [add1 (integer? integer? . - . integer?)])) (module* test-external racket (require (submod ..)) (require rackunit) (check-exn exn:fail? (λ _ (add1 3 3 (module+ test-internal (require rackunit) (check-equal? (add1 4.5 4.5) 7.0)) On Fri, May 22, 2015 at 11:37 AM, Anthony Carrico acarr...@memebeam.org wrote: Has this been an oversight? Do we need two official test submodules? One from the inside, and one from without. -- Anthony Carrico -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] test submodules vs tests in separate file
I usually prefer test submodules because I like the proximity to the code being tested. Plus in Emacs racket-mode I can fold/hide the test submodules if they ever become distracting. Exceptions to usually: - Even with the ability to hide/fold tests, if the ratio of tests to tested is really large, I may move tests to their own file. - If I'm implementing my own `#lang my-lang`, it's usually simpler to have a separate test file with `#lang my-lang` at the top. I observed that test submodules increase the start up time of racket scripts. Startup will be fastest if you `raco make` the foo.rkt file to a compiled/foo.zo bytecode file. When you `racket foo.rkt` (directly or via #!) it will load the compiled/foo.zo provided it's not older. (Otherwise the .rkt file must be parsed and expanded each/every time you run. This includes test submodules, even though they won't be run. In addition, expansion time can be significant with non-trivial macros, including but not limited to Typed Racket.) On Thu, May 21, 2015 at 6:25 AM, Atticus attic...@posteo.org wrote: Hello, What is the recommended way to add tests in racket? I was looking through the racket documentation and there are two options for adding tests, using test submodules or using a separate file for tests (rackunit documentation). Some authors seem to prefer one over the other for example pollen (https://github.com/mbutterick/pollen/tree/master/tests) uses separate files and the author of racket-2048 (https://github.com/danprager/racket-2048/blob/master/2048.rkt) uses test submodules. Are there any advantages/disadvantages of using test submodules vs separate test files? Or is it just a matter of personal preference? It looks like that test submodules are more convenient and flexible but I observed that test submodules increase the start up time of racket scripts. -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] test submodules vs tests in separate file
Three advantages of `test` submodules interspersed with the implementation code: * You're usually working on implementation and tests at the same time, and putting them adjacent in the same file is helpful (without fancy IDE support). * These tests constitute documentation for someone who has to maintain the code later, so, while they're looking at the code to understand it, they can also be looking at the tests, to speed along their understanding. * When the tests are in with the code, you can at a glance get some sense of what the test case coverage is like for a chunk of implementation, as well as scroll through the file quickly and see what's not tested. (Fancy tools could also tell you this, in addition to giving you code path coverage info that you can't get this way, but no reason to throw away this simple approach as well.) Submodules are one of my favorite newer features of Racket, and the `test` module is a great use of them. Nowadays, I usually only use separate files for testing when I have tests that are either very expensive (such that you don't want them to run every time you hit Run on the file in DrRacket) or for tests require external resources/conditions or human interaction (e.g., a particular server configuration). Neil V. -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] test submodules vs tests in separate file
On 05/21/2015 08:44 AM, Neil Van Dyke wrote: Three advantages of `test` submodules interspersed with the implementation code: It is worth mentioning that submodules don't work well with typed racket yet, so TR tests are often in another file. -- Anthony Carrico -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [racket-users] test submodules vs tests in separate file
Great advice, thank you very much. Neil Van Dyke n...@neilvandyke.org writes: Three advantages of `test` submodules interspersed with the implementation code: * You're usually working on implementation and tests at the same time, and putting them adjacent in the same file is helpful (without fancy IDE support). * These tests constitute documentation for someone who has to maintain the code later, so, while they're looking at the code to understand it, they can also be looking at the tests, to speed along their understanding. * When the tests are in with the code, you can at a glance get some sense of what the test case coverage is like for a chunk of implementation, as well as scroll through the file quickly and see what's not tested. (Fancy tools could also tell you this, in addition to giving you code path coverage info that you can't get this way, but no reason to throw away this simple approach as well.) Submodules are one of my favorite newer features of Racket, and the `test` module is a great use of them. Nowadays, I usually only use separate files for testing when I have tests that are either very expensive (such that you don't want them to run every time you hit Run on the file in DrRacket) or for tests require external resources/conditions or human interaction (e.g., a particular server configuration). Neil V. -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] test submodules vs tests in separate file
I usually prefer test submodules because I like the proximity to the code being tested. Plus in Emacs racket-mode I can fold/hide the test submodules if they ever become distracting. Nice feature. Btw thank you for making racket-mode :) Exceptions to usually: - Even with the ability to hide/fold tests, if the ratio of tests to tested is really large, I may move tests to their own file. - If I'm implementing my own `#lang my-lang`, it's usually simpler to have a separate test file with `#lang my-lang` at the top. That sounds very sensible. Test submodules as default and when tests get too large use separate test file. Startup will be fastest if you `raco make` the foo.rkt file to a compiled/foo.zo bytecode file. When you `racket foo.rkt` (directly or via #!) it will load the compiled/foo.zo provided it's not older. (Otherwise the .rkt file must be parsed and expanded each/every time you run. This includes test submodules, even though they won't be run. In addition, expansion time can be significant with non-trivial macros, including but not limited to Typed Racket.) Very interesting, this reduced the start up time significantly and my small script starts nearly instantly now. So for macro heavy code 'raco make' is the way to go. Can I use 'raco make' for everything or does it make debugging more difficult? Thank you very much for your help. Greg Hendershott greghendersh...@gmail.com writes: I usually prefer test submodules because I like the proximity to the code being tested. Plus in Emacs racket-mode I can fold/hide the test submodules if they ever become distracting. Exceptions to usually: - Even with the ability to hide/fold tests, if the ratio of tests to tested is really large, I may move tests to their own file. - If I'm implementing my own `#lang my-lang`, it's usually simpler to have a separate test file with `#lang my-lang` at the top. I observed that test submodules increase the start up time of racket scripts. Startup will be fastest if you `raco make` the foo.rkt file to a compiled/foo.zo bytecode file. When you `racket foo.rkt` (directly or via #!) it will load the compiled/foo.zo provided it's not older. (Otherwise the .rkt file must be parsed and expanded each/every time you run. This includes test submodules, even though they won't be run. In addition, expansion time can be significant with non-trivial macros, including but not limited to Typed Racket.) On Thu, May 21, 2015 at 6:25 AM, Atticus attic...@posteo.org wrote: Hello, What is the recommended way to add tests in racket? I was looking through the racket documentation and there are two options for adding tests, using test submodules or using a separate file for tests (rackunit documentation). Some authors seem to prefer one over the other for example pollen (https://github.com/mbutterick/pollen/tree/master/tests) uses separate files and the author of racket-2048 (https://github.com/danprager/racket-2048/blob/master/2048.rkt) uses test submodules. Are there any advantages/disadvantages of using test submodules vs separate test files? Or is it just a matter of personal preference? It looks like that test submodules are more convenient and flexible but I observed that test submodules increase the start up time of racket scripts. -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] test submodules vs tests in separate file
Startup will be fastest if you `raco make` the foo.rkt file to a compiled/foo.zo bytecode file. When you `racket foo.rkt` (directly or via #!) it will load the compiled/foo.zo provided it's not older. Not compiled/foo.zo; it would be compiled/foo_rkt.zo. -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] test submodules vs tests in separate file
(Otherwise the .rkt file must be parsed and expanded each/every time you run. This includes test submodules, even though they won't be run. In addition, expansion time can be significant with non-trivial macros, including but not limited to Typed Racket.) Very interesting, this reduced the start up time significantly and my small script starts nearly instantly now. So for macro heavy code 'raco make' is the way to go. Can I use 'raco make' for everything or does it make debugging more difficult? I haven't experienced it making debugging more difficult. Do you mean the case where you update your .rkt but don't re-make, so that the .zo is older? Racket will ignore the zo. As a result, although you lose the startup speed-up, you don't get any confusion from it running outdated code. Also, Dr Racket has an option to make compiled zos for you automatically (but racket-mode doesn't). By the way, I mentioned `raco make` because it sounded like you were working on individual script files. People often run `raco make` indirectly -- if you make your project a collection with `raco link`, or make it a package, then `raco setup` will run `raco make` (among other things). -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] test submodules vs tests in separate file
Three advantages of `test` submodules interspersed with the implementation code: Here's a fourth: no need for tricks like require/expose to sneak around interfaces. -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] test submodules vs tests in separate file
I thought that the compilded code would have fewer debugging information (source code location etc) or not able to use the stepper. I have not used the stepper in racket yet (but the stepper in gambit scheme which is really useful at least for a beginner like me). Oh I see what you mean. No, not exactly. As I understand it, the bytecode .zo file simply caches the result of reading and expanding the .rkt file (so it doesn't need to happen repeatedly). Either way, fresh from .rkt or cached from .zo, the expanded code gets JIT compiled at runtime to native code. Although expansion and JIT optimization does mean that some interesting information might be discarded, I think it would be more accurate to say that a good debugging experience requires additional information to be added. The way an interactive step debugger works in Racket is that expansion happens differently. Your code is annotated -- extra code is inserted to support things like breakpoints and capturing continuation marks (stack frames). When you run your program in the debugger, you're actually running that enhanced/annotated version of your program. Anyway the Dr Racket debugger automatically ignores the zo files and does a fresh expansion to add those annotations. But as I said, this isn't really because the zos lost information, it's because debugging needs extra information that's normally never there in the first place. -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] test submodules vs tests in separate file
Are there any advantages/disadvantages of using test submodules vs separate test files? Or is it just a matter of personal preference? It looks like that test submodules are more convenient and flexible but I observed that test submodules increase the start up time of racket scripts. If you're using contracts, you want your tests to cross the contract boundaries. If you attach your contracts at the module boundary (a common practice), then submodule tests will not trigger the contracts. (Example below.) So putting these tests in a separate file is the better option. ; #lang racket (define/contract (add1 x y) (integer? integer? . - . integer?) (+ x y)) (provide (contract-out [add2 (integer? integer? . - . integer?)])) (define (add2 x y) (+ x y)) (module+ test (require rackunit) (check-exn exn:fail? (λ _ (add1 20.5 21.5))) (check-equal? (add2 20.5 21.5) 42.0)) ; surprise! ; -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] test submodules vs tests in separate file
Do you mean the case where you update your .rkt but don't re-make, so that the .zo is older? Racket will ignore the zo. As a result, although you lose the startup speed-up, you don't get any confusion from it running outdated code. I thought that the compilded code would have fewer debugging information (source code location etc) or not able to use the stepper. I have not used the stepper in racket yet (but the stepper in gambit scheme which is really useful at least for a beginner like me). By the way, I mentioned `raco make` because it sounded like you were working on individual script files. People often run `raco make` indirectly -- if you make your project a collection with `raco link`, or make it a package, then `raco setup` will run `raco make` (among other things). Yes that's right, I'm working on a simple executable unix script. My strategy to learn racket is to start as simple as possible and then extend the simple programms and learn more racket features by the way, for example packaging, using macros, contracts etc.. Greg Hendershott greghendersh...@gmail.com writes: (Otherwise the .rkt file must be parsed and expanded each/every time you run. This includes test submodules, even though they won't be run. In addition, expansion time can be significant with non-trivial macros, including but not limited to Typed Racket.) Very interesting, this reduced the start up time significantly and my small script starts nearly instantly now. So for macro heavy code 'raco make' is the way to go. Can I use 'raco make' for everything or does it make debugging more difficult? I haven't experienced it making debugging more difficult. Do you mean the case where you update your .rkt but don't re-make, so that the .zo is older? Racket will ignore the zo. As a result, although you lose the startup speed-up, you don't get any confusion from it running outdated code. Also, Dr Racket has an option to make compiled zos for you automatically (but racket-mode doesn't). By the way, I mentioned `raco make` because it sounded like you were working on individual script files. People often run `raco make` indirectly -- if you make your project a collection with `raco link`, or make it a package, then `raco setup` will run `raco make` (among other things). -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
