emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
* [Proposal] Source Blocks with Post-Extensions
@ 2019-04-22  9:00 Dmitrii Korobeinikov
  2019-04-22 16:51 ` Berry, Charles
  2019-04-22 20:59 ` Tim Cross
  0 siblings, 2 replies; 12+ messages in thread
From: Dmitrii Korobeinikov @ 2019-04-22  9:00 UTC (permalink / raw)
  To: emacs-orgmode


[-- Attachment #1.1: Type: text/plain, Size: 2140 bytes --]

For your convenience, I have attached this e-mail as an org-mode file.

When I write several source blocks, which depend on one another, I tend to
debug them one by one.

So, I write this function and test it:

#+NAME: square
#+BEGIN_SRC python
    square = lambda x: x * x
    return square(5)
#+END_SRC

#+RESULTS: square
: 25

After I see that the test is successful, I write this client function:

#+BEGIN_SRC python :noweb yes
    <<square>>
    return 5 + square(5)
#+END_SRC

#+RESULTS:
: 25

And here, to get the correct result, I have to remove the ~return
square(5)~ line in ~<<square>>~.
But I don't want to lose testing!
So I find nothing better to do than to seperate the source block:

#+NAME: square-1
#+BEGIN_SRC python
    square = lambda x: x * x
#+END_SRC

And, by the way, there was no error/warning that I have just redefined
~<<square>>~,
so, for the test-snippet below to work, I renamed it to ~<<square-1>>~.
I think the org-mode team is aware of it, but anyway:

- [ ] no error checking of the description of a code block.

#+NAME: square-1-tester
#+BEGIN_SRC python :noweb yes
  <<square-1>>
  return square(5)
#+END_SRC

#+RESULTS: square-1-tester
: 25

- [ ] For every such source block used for testing purposes, you have to
repeat the inclusion statement and part of the name, which is cumbersome.

A fair solution is maybe to extend the block like this:

#+NAME: square-1
#+BEGIN_SRC python
  square = lambda x: x * x
#+END_SRC
  return square(5)
#+END_SRC_TEST

When I call this individually, the test part would run, but when I :noweb
it in another block, the test part would be ommited.

As an extension of this idea, it could be useful to have several test
attachments like this, each producing its own result. Maybe, the TEST part
could as well be ommited. Custom names are also an option:

#+NAME: square-multiple
#+BEGIN_SRC python
  square = lambda x: x * x
#+END_SRC
  return square(5)
#+END_SRC NAME: ext_1
  return square(10)
#+END_SRC NAME: ext_2

#+RESULTS: square-multiple-ext-1
: 25

#+RESULTS: square-multiple-ext-2
: 100

Overall, these techniques should reduce noise and increase usability.

[-- Attachment #1.2: Type: text/html, Size: 3204 bytes --]

[-- Attachment #2: org-test-suite.org --]
[-- Type: application/octet-stream, Size: 2182 bytes --]

#+TITLE: [Proposal] Source Blocks with Post-Extensions
#+AUTHOR: Dmitrii Korobeinikov
#+EMAIL: dim1212k@gmail.com

When I write several source blocks, which depend on one another, I tend to debug them one by one.

So, I write this function and test it:

#+NAME: square
#+BEGIN_SRC python
    square = lambda x: x * x
    return square(5)
#+END_SRC

#+RESULTS: square
: 25

After I see that the test is successful, I write this client function:

#+BEGIN_SRC python :noweb yes
    <<square>>
    return 5 + square(5)
#+END_SRC

#+RESULTS:
: 25

And here, to get the correct result, I have to remove the ~return square(5)~ line in ~<<square>>~.
But I don't want to lose testing!
So I find nothing better to do than to seperate the source block:

#+NAME: square-1
#+BEGIN_SRC python
    square = lambda x: x * x
#+END_SRC

And, by the way, there was no error/warning that I have just redefined ~<<square>>~,
so, for the test-snippet below to work, I renamed it to ~<<square-1>>~.
I think the org-mode team is aware of it, but anyway:

- [ ] no error checking of the description of a code block.

#+NAME: square-1-tester
#+BEGIN_SRC python :noweb yes
  <<square-1>>
  return square(5)
#+END_SRC

#+RESULTS: square-1-tester
: 25

- [ ] For every such source block used for testing purposes, you have to repeat the inclusion statement and part of the name, which is cumbersome.

A fair solution is maybe extend the block like this:

#+NAME: square-1
#+BEGIN_SRC python
  square = lambda x: x * x
#+END_SRC
  return square(5)
#+END_SRC_TEST

When I call this individually, the test part would run, but when I :noweb it in another block, the test part would be ommited.

As an extension of this idea, it could be useful to have several test attachments like this, each producing its own result. Maybe, the TEST part could as well be ommited. Custom names are also an option:

#+NAME: square-multiple
#+BEGIN_SRC python
  square = lambda x: x * x
#+END_SRC
  return square(5)
#+END_SRC NAME: ext_1 
  return square(10)
#+END_SRC NAME: ext_2 

#+RESULTS: square-multiple-ext-1
: 25

#+RESULTS: square-multiple-ext-2
: 100

Overall, these techniques should reduce noise and increase usability.

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [Proposal] Source Blocks with Post-Extensions
  2019-04-22  9:00 [Proposal] Source Blocks with Post-Extensions Dmitrii Korobeinikov
@ 2019-04-22 16:51 ` Berry, Charles
  2019-04-22 17:15   ` Dmitrii Korobeinikov
  2019-04-22 20:59 ` Tim Cross
  1 sibling, 1 reply; 12+ messages in thread
From: Berry, Charles @ 2019-04-22 16:51 UTC (permalink / raw)
  To: Dmitrii Korobeinikov; +Cc: emacs-orgmode

It looks like you want the :epilogue header argument. See inline.

> On Apr 22, 2019, at 2:00 AM, Dmitrii Korobeinikov <dim1212k@gmail.com> wrote:
> 
> When I write several source blocks, which depend on one another, I tend to debug them one by one.
> 
> So, I write this function and test it:
> 
> #+NAME: square
> #+BEGIN_SRC python
>     square = lambda x: x * x
>     return square(5)
> #+END_SRC
> 
> #+RESULTS: square
> : 25
> 


Equivalently, you could run this:

#+NAME: square
#+BEGIN_SRC python :epilogue  return square(5)
    square = lambda x: x * x
#+END_SRC



> After I see that the test is successful, I write this client function:
> 
> #+BEGIN_SRC python :noweb yes
>     <<square>>
>     return 5 + square(5)
> #+END_SRC
> 
> #+RESULTS:
> : 25
> 
> And here, to get the correct result, I have to remove the ~return square(5)~ line in ~<<square>>~.
> But I don't want to lose testing!
> S

With my version of `square`, the epilogue is not included. 

So it works as you want it to.

HTH,

Chuck

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [Proposal] Source Blocks with Post-Extensions
  2019-04-22 16:51 ` Berry, Charles
@ 2019-04-22 17:15   ` Dmitrii Korobeinikov
  2019-04-22 17:31     ` Berry, Charles
  0 siblings, 1 reply; 12+ messages in thread
From: Dmitrii Korobeinikov @ 2019-04-22 17:15 UTC (permalink / raw)
  To: Berry, Charles; +Cc: emacs-orgmode

[-- Attachment #1: Type: text/plain, Size: 1469 bytes --]

Thank you!
That's a handy technique and it does help.
As I understand, there's no way to extend that to multiple lines?
One-liners for tests are enough sometimes, but not always.
For those cases, it is cumbersome to split as well.

пн, 22 апр. 2019 г. в 22:51, Berry, Charles <ccberry@ucsd.edu>:

> It looks like you want the :epilogue header argument. See inline.
>
> > On Apr 22, 2019, at 2:00 AM, Dmitrii Korobeinikov <dim1212k@gmail.com>
> wrote:
> >
> > When I write several source blocks, which depend on one another, I tend
> to debug them one by one.
> >
> > So, I write this function and test it:
> >
> > #+NAME: square
> > #+BEGIN_SRC python
> >     square = lambda x: x * x
> >     return square(5)
> > #+END_SRC
> >
> > #+RESULTS: square
> > : 25
> >
>
>
> Equivalently, you could run this:
>
> #+NAME: square
> #+BEGIN_SRC python :epilogue  return square(5)
>     square = lambda x: x * x
> #+END_SRC
>
>
>
> > After I see that the test is successful, I write this client function:
> >
> > #+BEGIN_SRC python :noweb yes
> >     <<square>>
> >     return 5 + square(5)
> > #+END_SRC
> >
> > #+RESULTS:
> > : 25
> >
> > And here, to get the correct result, I have to remove the ~return
> square(5)~ line in ~<<square>>~.
> > But I don't want to lose testing!
> > S
>
> With my version of `square`, the epilogue is not included.
>
> So it works as you want it to.
>
> HTH,
>
> Chuck
>
>
>

[-- Attachment #2: Type: text/html, Size: 2166 bytes --]

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [Proposal] Source Blocks with Post-Extensions
  2019-04-22 17:15   ` Dmitrii Korobeinikov
@ 2019-04-22 17:31     ` Berry, Charles
  2019-04-24 19:05       ` Dmitrii Korobeinikov
  0 siblings, 1 reply; 12+ messages in thread
From: Berry, Charles @ 2019-04-22 17:31 UTC (permalink / raw)
  To: Dmitrii Korobeinikov; +Cc: emacs-orgmode



> On Apr 22, 2019, at 10:15 AM, Dmitrii Korobeinikov <dim1212k@gmail.com> wrote:
> 
> Thank you!
> That's a handy technique and it does help.
> As I understand, there's no way to extend that to multiple lines?

AFAICS, no there is no way to split the :epilogue arg to multiple lines.

Of course, you can always follow a src block that provides a function with another src block that imports the code via noweb and then tests the function with as many lines of code as you need. 

Chuck

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [Proposal] Source Blocks with Post-Extensions
  2019-04-22  9:00 [Proposal] Source Blocks with Post-Extensions Dmitrii Korobeinikov
  2019-04-22 16:51 ` Berry, Charles
@ 2019-04-22 20:59 ` Tim Cross
  1 sibling, 0 replies; 12+ messages in thread
From: Tim Cross @ 2019-04-22 20:59 UTC (permalink / raw)
  To: emacs-orgmode


YMMV, but personally, I think the real problem here is combining your
tests with your definition. i.e. square = lambda x: x * x is your real
code block while the return line is really just part of
testing/debugging and should not be in your definition block.

Tests are very important, but I find they 'clutter' the code and make it
harder to read/think about the core functionality - especially after
leaving and returning some time later to worik on the core code.

My approach is to keep the code blocks as 'pure' as possible and put all
the tests in a separate section of the org file. It does make code test
coverage a bit more challenging because you don't have the two 'side by
side', but I find that is offset by the increased clarity with the main
code.

just an alternative view ....

Dmitrii Korobeinikov <dim1212k@gmail.com> writes:

> For your convenience, I have attached this e-mail as an org-mode file.
>
> When I write several source blocks, which depend on one another, I tend to
> debug them one by one.
>
> So, I write this function and test it:
>
> #+NAME: square
> #+BEGIN_SRC python
>     square = lambda x: x * x
>     return square(5)
> #+END_SRC
>
> #+RESULTS: square
> : 25
>
> After I see that the test is successful, I write this client function:
>
> #+BEGIN_SRC python :noweb yes
>     <<square>>
>     return 5 + square(5)
> #+END_SRC
>
> #+RESULTS:
> : 25
>
> And here, to get the correct result, I have to remove the ~return
> square(5)~ line in ~<<square>>~.
> But I don't want to lose testing!
> So I find nothing better to do than to seperate the source block:
>
> #+NAME: square-1
> #+BEGIN_SRC python
>     square = lambda x: x * x
> #+END_SRC
>
> And, by the way, there was no error/warning that I have just redefined
> ~<<square>>~,
> so, for the test-snippet below to work, I renamed it to ~<<square-1>>~.
> I think the org-mode team is aware of it, but anyway:
>
> - [ ] no error checking of the description of a code block.
>
> #+NAME: square-1-tester
> #+BEGIN_SRC python :noweb yes
>   <<square-1>>
>   return square(5)
> #+END_SRC
>
> #+RESULTS: square-1-tester
> : 25
>
> - [ ] For every such source block used for testing purposes, you have to
> repeat the inclusion statement and part of the name, which is cumbersome.
>
> A fair solution is maybe to extend the block like this:
>
> #+NAME: square-1
> #+BEGIN_SRC python
>   square = lambda x: x * x
> #+END_SRC
>   return square(5)
> #+END_SRC_TEST
>
> When I call this individually, the test part would run, but when I :noweb
> it in another block, the test part would be ommited.
>
> As an extension of this idea, it could be useful to have several test
> attachments like this, each producing its own result. Maybe, the TEST part
> could as well be ommited. Custom names are also an option:
>
> #+NAME: square-multiple
> #+BEGIN_SRC python
>   square = lambda x: x * x
> #+END_SRC
>   return square(5)
> #+END_SRC NAME: ext_1
>   return square(10)
> #+END_SRC NAME: ext_2
>
> #+RESULTS: square-multiple-ext-1
> : 25
>
> #+RESULTS: square-multiple-ext-2
> : 100
>
> Overall, these techniques should reduce noise and increase usability.


-- 
Tim Cross

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [Proposal] Source Blocks with Post-Extensions
  2019-04-22 17:31     ` Berry, Charles
@ 2019-04-24 19:05       ` Dmitrii Korobeinikov
  2019-06-26 22:09         ` Martin Alsinet
  0 siblings, 1 reply; 12+ messages in thread
From: Dmitrii Korobeinikov @ 2019-04-24 19:05 UTC (permalink / raw)
  To: Berry, Charles; +Cc: emacs-orgmode

[-- Attachment #1: Type: text/plain, Size: 1116 bytes --]

Sorry for not answering these two days.

You are right, that's an option.
But I just don't think that's the best possible one - for usability.

Introducing this would imply architectural decisions, so it might not be
immediately clear if it's right or not.
Especially that the improvement might not seem that big.
So, I understand that.

I have proposed buffer lenses today and they seem like something that can
solve the issue from the user side. Hopefully they will get some traction.

пн, 22 апр. 2019 г. в 23:31, Berry, Charles <ccberry@ucsd.edu>:

>
>
> > On Apr 22, 2019, at 10:15 AM, Dmitrii Korobeinikov <dim1212k@gmail.com>
> wrote:
> >
> > Thank you!
> > That's a handy technique and it does help.
> > As I understand, there's no way to extend that to multiple lines?
>
> AFAICS, no there is no way to split the :epilogue arg to multiple lines.
>
> Of course, you can always follow a src block that provides a function with
> another src block that imports the code via noweb and then tests the
> function with as many lines of code as you need.
>
> Chuck
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 1625 bytes --]

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [Proposal] Source Blocks with Post-Extensions
  2019-04-24 19:05       ` Dmitrii Korobeinikov
@ 2019-06-26 22:09         ` Martin Alsinet
  2019-07-03 16:02           ` Dmitrii Korobeinikov
  2019-07-26 12:02           ` Ken Mankoff
  0 siblings, 2 replies; 12+ messages in thread
From: Martin Alsinet @ 2019-06-26 22:09 UTC (permalink / raw)
  To: Dmitrii Korobeinikov; +Cc: emacs-orgmode, Berry, Charles

[-- Attachment #1: Type: text/plain, Size: 2704 bytes --]

Dmitrii,

I use a different approach, where I tangle the source into files in modules
and then I import those modules from other blocks.
This allows me to organize my document with different sections for the code
and its tests, which then get exported into their corresponding files.


* Square Function

This function receives a number and returns its square

#+BEGIN_SRC python :tangle ./utils/math.py :mkdirp yes
def square(x):
    return x * x
#+END_SRC

** __init__.py (module setup)

#+begin_src python :tangle ./utils/__init__.py :mkdirp yes
from utils.math import square

#+end_src

** Test cases

1. The square of five should be 25
2. The square of zero should be 0
3. The square of a negative number should be positive

#+BEGIN_SRC python :tangle ./utils/test_square.py :mkdirp yes
from utils.math import square

def test_square_of_five():
    assert square(5) == 25

def test_square_of_zero():
    assert square(0) == 0

def test_square_of_negative():
    assert square(-5) > 0
#+END_SRC

*** Run tests

#+begin_src sh :results output raw
pytest ./utils
#+end_src

#+RESULTS:
============================= test session starts
==============================
platform linux -- Python 3.7.3, pytest-4.6.3, py-1.8.0, pluggy-0.12.0
rootdir: /app
collected 3 items

utils/test_square.py ...
[100%]

=========================== 3 passed in 0.08 seconds
===========================






On Wed, Apr 24, 2019 at 2:19 PM Dmitrii Korobeinikov <dim1212k@gmail.com>
wrote:

> Sorry for not answering these two days.
>
> You are right, that's an option.
> But I just don't think that's the best possible one - for usability.
>
> Introducing this would imply architectural decisions, so it might not be
> immediately clear if it's right or not.
> Especially that the improvement might not seem that big.
> So, I understand that.
>
> I have proposed buffer lenses today and they seem like something that can
> solve the issue from the user side. Hopefully they will get some traction.
>
> пн, 22 апр. 2019 г. в 23:31, Berry, Charles <ccberry@ucsd.edu>:
>
>>
>>
>> > On Apr 22, 2019, at 10:15 AM, Dmitrii Korobeinikov <dim1212k@gmail.com>
>> wrote:
>> >
>> > Thank you!
>> > That's a handy technique and it does help.
>> > As I understand, there's no way to extend that to multiple lines?
>>
>> AFAICS, no there is no way to split the :epilogue arg to multiple lines.
>>
>> Of course, you can always follow a src block that provides a function
>> with another src block that imports the code via noweb and then tests the
>> function with as many lines of code as you need.
>>
>> Chuck
>>
>>
>>
>>

[-- Attachment #2: Type: text/html, Size: 7912 bytes --]

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [Proposal] Source Blocks with Post-Extensions
  2019-06-26 22:09         ` Martin Alsinet
@ 2019-07-03 16:02           ` Dmitrii Korobeinikov
  2019-07-26 12:02           ` Ken Mankoff
  1 sibling, 0 replies; 12+ messages in thread
From: Dmitrii Korobeinikov @ 2019-07-03 16:02 UTC (permalink / raw)
  To: Martin Alsinet; +Cc: emacs-orgmode, Berry, Charles

[-- Attachment #1: Type: text/plain, Size: 3233 bytes --]

Dear Martin,

Your approach to test cases is quite valuable for more structured projects
and for automation. For something that's either quick&dirty or w/out much
architectural certainty to it, I would still prefer the handy one-liners.
Nonetheless, thanks for the example!

Best,
Dmitrii.

чт, 27 июн. 2019 г. в 04:09, Martin Alsinet <martin@alsinet.com.ar>:

> Dmitrii,
>
> I use a different approach, where I tangle the source into files in
> modules and then I import those modules from other blocks.
> This allows me to organize my document with different sections for the
> code and its tests, which then get exported into their corresponding files.
>
>
> * Square Function
>
> This function receives a number and returns its square
>
> #+BEGIN_SRC python :tangle ./utils/math.py :mkdirp yes
> def square(x):
>     return x * x
> #+END_SRC
>
> ** __init__.py (module setup)
>
> #+begin_src python :tangle ./utils/__init__.py :mkdirp yes
> from utils.math import square
>
> #+end_src
>
> ** Test cases
>
> 1. The square of five should be 25
> 2. The square of zero should be 0
> 3. The square of a negative number should be positive
>
> #+BEGIN_SRC python :tangle ./utils/test_square.py :mkdirp yes
> from utils.math import square
>
> def test_square_of_five():
>     assert square(5) == 25
>
> def test_square_of_zero():
>     assert square(0) == 0
>
> def test_square_of_negative():
>     assert square(-5) > 0
> #+END_SRC
>
> *** Run tests
>
> #+begin_src sh :results output raw
> pytest ./utils
> #+end_src
>
> #+RESULTS:
> ============================= test session starts
> ==============================
> platform linux -- Python 3.7.3, pytest-4.6.3, py-1.8.0, pluggy-0.12.0
> rootdir: /app
> collected 3 items
>
> utils/test_square.py ...
> [100%]
>
> =========================== 3 passed in 0.08 seconds
> ===========================
>
>
>
>
>
>
> On Wed, Apr 24, 2019 at 2:19 PM Dmitrii Korobeinikov <dim1212k@gmail.com>
> wrote:
>
>> Sorry for not answering these two days.
>>
>> You are right, that's an option.
>> But I just don't think that's the best possible one - for usability.
>>
>> Introducing this would imply architectural decisions, so it might not be
>> immediately clear if it's right or not.
>> Especially that the improvement might not seem that big.
>> So, I understand that.
>>
>> I have proposed buffer lenses today and they seem like something that can
>> solve the issue from the user side. Hopefully they will get some traction.
>>
>> пн, 22 апр. 2019 г. в 23:31, Berry, Charles <ccberry@ucsd.edu>:
>>
>>>
>>>
>>> > On Apr 22, 2019, at 10:15 AM, Dmitrii Korobeinikov <dim1212k@gmail.com>
>>> wrote:
>>> >
>>> > Thank you!
>>> > That's a handy technique and it does help.
>>> > As I understand, there's no way to extend that to multiple lines?
>>>
>>> AFAICS, no there is no way to split the :epilogue arg to multiple lines.
>>>
>>> Of course, you can always follow a src block that provides a function
>>> with another src block that imports the code via noweb and then tests the
>>> function with as many lines of code as you need.
>>>
>>> Chuck
>>>
>>>
>>>
>>>

[-- Attachment #2: Type: text/html, Size: 8543 bytes --]

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [Proposal] Source Blocks with Post-Extensions
  2019-06-26 22:09         ` Martin Alsinet
  2019-07-03 16:02           ` Dmitrii Korobeinikov
@ 2019-07-26 12:02           ` Ken Mankoff
  2019-07-26 12:58             ` Martin Alsinet
  1 sibling, 1 reply; 12+ messages in thread
From: Ken Mankoff @ 2019-07-26 12:02 UTC (permalink / raw)
  To: Martin Alsinet; +Cc: Dmitrii Korobeinikov, emacs-orgmode, Berry, Charles

Hi Martin,

On 2019-06-26 at 18:09 -04, Martin Alsinet <martin@alsinet.com.ar> wrote...
> I use a different approach, where I tangle the source into files in
> modules and then I import those modules from other blocks. This allows
> me to organize my document with different sections for the code and
> its tests, which then get exported into their corresponding files.

Thanks for providing this pytest code below. It runs nicely because your tests pass. It does not run if a test fails. The shell block that runs pytest reports

Babel evaluation exited with code 1
Code block produced no output.

Do you have some way of capturing failed pytest tests in Org Babel?

Thanks,

  -k.
  
> * Square Function
>
> This function receives a number and returns its square
>
> #+BEGIN_SRC python :tangle ./utils/math.py :mkdirp yes
> def square(x):
>     return x * x
> #+END_SRC
>
> ** __init__.py (module setup)
>
> #+begin_src python :tangle ./utils/__init__.py :mkdirp yes
> from utils.math import square
>
> #+end_src
>
> ** Test cases
>
> 1. The square of five should be 25
> 2. The square of zero should be 0
> 3. The square of a negative number should be positive
>
> #+BEGIN_SRC python :tangle ./utils/test_square.py :mkdirp yes
> from utils.math import square
>
> def test_square_of_five():
>     assert square(5) == 25
>
> def test_square_of_zero():
>     assert square(0) == 0
>
> def test_square_of_negative():
>     assert square(-5) > 0
> #+END_SRC
>
> *** Run tests
>
> #+begin_src sh :results output raw
> pytest ./utils
> #+end_src
>
> #+RESULTS:
> ============================= test session starts
> ==============================
> platform linux -- Python 3.7.3, pytest-4.6.3, py-1.8.0, pluggy-0.12.0
> rootdir: /app
> collected 3 items
>
> utils/test_square.py ...
> [100%]
>
> =========================== 3 passed in 0.08 seconds
> ===========================
>
>

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [Proposal] Source Blocks with Post-Extensions
  2019-07-26 12:02           ` Ken Mankoff
@ 2019-07-26 12:58             ` Martin Alsinet
  2019-07-26 15:18               ` Ken Mankoff
  0 siblings, 1 reply; 12+ messages in thread
From: Martin Alsinet @ 2019-07-26 12:58 UTC (permalink / raw)
  To: Ken Mankoff; +Cc: Dmitrii Korobeinikov, emacs-orgmode, Berry, Charles

[-- Attachment #1: Type: text/plain, Size: 2492 bytes --]

Ken,

I usually have a shell buffer nearby and go there to inspect the failed
tests when I get no output.
The problem is that shell blocks do not capture stderr. John Kitchin wrote
a blog post
<http://kitchingroup.cheme.cmu.edu/blog/2015/01/04/Redirecting-stderr-in-org-mode-shell-blocks/>
about this problem and provided a solution that may work for you, but I
have not tried it yet.

Martin

On Fri, Jul 26, 2019 at 7:02 AM Ken Mankoff <mankoff@gmail.com> wrote:

> Hi Martin,
>
> On 2019-06-26 at 18:09 -04, Martin Alsinet <martin@alsinet.com.ar>
> wrote...
> > I use a different approach, where I tangle the source into files in
> > modules and then I import those modules from other blocks. This allows
> > me to organize my document with different sections for the code and
> > its tests, which then get exported into their corresponding files.
>
> Thanks for providing this pytest code below. It runs nicely because your
> tests pass. It does not run if a test fails. The shell block that runs
> pytest reports
>
> Babel evaluation exited with code 1
> Code block produced no output.
>
> Do you have some way of capturing failed pytest tests in Org Babel?
>
> Thanks,
>
>   -k.
>
> > * Square Function
> >
> > This function receives a number and returns its square
> >
> > #+BEGIN_SRC python :tangle ./utils/math.py :mkdirp yes
> > def square(x):
> >     return x * x
> > #+END_SRC
> >
> > ** __init__.py (module setup)
> >
> > #+begin_src python :tangle ./utils/__init__.py :mkdirp yes
> > from utils.math import square
> >
> > #+end_src
> >
> > ** Test cases
> >
> > 1. The square of five should be 25
> > 2. The square of zero should be 0
> > 3. The square of a negative number should be positive
> >
> > #+BEGIN_SRC python :tangle ./utils/test_square.py :mkdirp yes
> > from utils.math import square
> >
> > def test_square_of_five():
> >     assert square(5) == 25
> >
> > def test_square_of_zero():
> >     assert square(0) == 0
> >
> > def test_square_of_negative():
> >     assert square(-5) > 0
> > #+END_SRC
> >
> > *** Run tests
> >
> > #+begin_src sh :results output raw
> > pytest ./utils
> > #+end_src
> >
> > #+RESULTS:
> > ============================= test session starts
> > ==============================
> > platform linux -- Python 3.7.3, pytest-4.6.3, py-1.8.0, pluggy-0.12.0
> > rootdir: /app
> > collected 3 items
> >
> > utils/test_square.py ...
> > [100%]
> >
> > =========================== 3 passed in 0.08 seconds
> > ===========================
> >
> >
>

[-- Attachment #2: Type: text/html, Size: 3364 bytes --]

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [Proposal] Source Blocks with Post-Extensions
  2019-07-26 12:58             ` Martin Alsinet
@ 2019-07-26 15:18               ` Ken Mankoff
  2019-07-26 15:52                 ` Martin Alsinet
  0 siblings, 1 reply; 12+ messages in thread
From: Ken Mankoff @ 2019-07-26 15:18 UTC (permalink / raw)
  To: Martin Alsinet; +Cc: Dmitrii Korobeinikov, emacs-orgmode, Berry, Charles


On 2019-07-26 at 08:58 -04, Martin Alsinet <martin@alsinet.com.ar> wrote...
> I usually have a shell buffer nearby and go there to inspect the
> failed tests when I get no output. The problem is that shell blocks do
> not capture stderr. John Kitchin wrote a blog post
> <http://kitchingroup.cheme.cmu.edu/blog/2015/01/04/Redirecting-stderr-in-org-mode-shell-blocks/>
> about this problem and provided a solution that may work for you, but
> I have not tried it yet.

Ah yes... from my own comments there:

#+begin_src sh :results raw drawer :prologue "exec 2>&1" :epilogue ":"
python -m pytest ./utils
#+end_src

Thanks for reminding me about my past self.

  -k.

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [Proposal] Source Blocks with Post-Extensions
  2019-07-26 15:18               ` Ken Mankoff
@ 2019-07-26 15:52                 ` Martin Alsinet
  0 siblings, 0 replies; 12+ messages in thread
From: Martin Alsinet @ 2019-07-26 15:52 UTC (permalink / raw)
  To: Ken Mankoff; +Cc: Dmitrii Korobeinikov, emacs-orgmode, Berry, Charles

[-- Attachment #1: Type: text/plain, Size: 972 bytes --]

Well Ken, you improved my workflow right there, I am going to add the
:prologue trick to my shell properties header and get the test error output
in the results block.

Thank you right back!

On Fri, Jul 26, 2019 at 10:18 AM Ken Mankoff <mankoff@gmail.com> wrote:

>
> On 2019-07-26 at 08:58 -04, Martin Alsinet <martin@alsinet.com.ar>
> wrote...
> > I usually have a shell buffer nearby and go there to inspect the
> > failed tests when I get no output. The problem is that shell blocks do
> > not capture stderr. John Kitchin wrote a blog post
> > <
> http://kitchingroup.cheme.cmu.edu/blog/2015/01/04/Redirecting-stderr-in-org-mode-shell-blocks/
> >
> > about this problem and provided a solution that may work for you, but
> > I have not tried it yet.
>
> Ah yes... from my own comments there:
>
> #+begin_src sh :results raw drawer :prologue "exec 2>&1" :epilogue ":"
> python -m pytest ./utils
> #+end_src
>
> Thanks for reminding me about my past self.
>
>   -k.
>

[-- Attachment #2: Type: text/html, Size: 1623 bytes --]

^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2019-07-26 15:52 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-04-22  9:00 [Proposal] Source Blocks with Post-Extensions Dmitrii Korobeinikov
2019-04-22 16:51 ` Berry, Charles
2019-04-22 17:15   ` Dmitrii Korobeinikov
2019-04-22 17:31     ` Berry, Charles
2019-04-24 19:05       ` Dmitrii Korobeinikov
2019-06-26 22:09         ` Martin Alsinet
2019-07-03 16:02           ` Dmitrii Korobeinikov
2019-07-26 12:02           ` Ken Mankoff
2019-07-26 12:58             ` Martin Alsinet
2019-07-26 15:18               ` Ken Mankoff
2019-07-26 15:52                 ` Martin Alsinet
2019-04-22 20:59 ` Tim Cross

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).