I usually make clone of the whole content of a module being tested as a first child of a @test node, and put there in the @test node @others directive at the top of body. After @others I write code that tests some function from the module.
Quite often I start developing a module without creating an external file. The whole development module is under one node that is cloned under several @test nodes, and only after I am satisfied with the code, I just make another clone and put it under some @clean or @file node as the only top level child to create external file. This works very well for me when developing Python. When I am writing in CoffeeScript I use cloned content of a module in two different external files: one is a regular CoffeeScript module, and the other is saved under /test/ folder and usually in a file named "test_<module>.coffee". [image: leo-unit-testing.png] For example in the above picture you can see two @clean nodes: 1. @clean coffee/ev-3.coffee 2. @clean test/spec/spec3-1.coffee Both of this two nodes have under them cloned node `ev-3 kod` which contains all definitions (functions, constants, singleton instances, ...). Node named 'izEvidencije` contains just some comments and @others line. So, all those definitions are defined and present in both files coffee/ev-3.coffee and test/spec/spec3-1.coffee. In the spec3-1.coffee there is a node `specifikacije` which contains all specs that are describing (and testing) behavior of ev-3.coffee module. For Python development, it is even easier because Leo executes test nodes on the fly, so there is no need for the external test file, but if you do wish to create test files and use some other test runner you can use the same technique as in the above example for CoffeeScript. HTH Vitalije On Saturday, October 13, 2018 at 12:23:32 AM UTC+2, MN wrote: > > Any node, but @test or @button nodes are easiest to use. >> >> Is that defined somewhere? >>> >> >> Yes, in the next sentence. >> > > The sentence can be parsed in two ways: > > "This node (in the Leo outline) defines your development environment. You > can use an @test node, an @button node, or an @command node" > > I read it as "There is something called a dev node" and "You can make a > dev node a @test, @button or @command node". It sounded like a dev node is > a node with a special property (e.g. a cloned node is visually different > from a regular node), and then you can make THAT dev node a @test node. I > think a better phrasing would be: > > "A dev node is defined as any node that is either a @test, @button or > @command node." > > For the examples you gave (and your other comments in the group), it seems > like I cannot put the unit test in its own node (even as a sibling)? > > On Fri, Oct 12, 2018 at 2:11 AM Edward K. Ream <[email protected] > <javascript:>> wrote: > >> On Thursday, October 11, 2018 at 4:17:07 PM UTC-5, MN wrote: >> >> > What is a dev node? >> >> Any node, but @test or @button nodes are easiest to use. >> >> Is that defined somewhere? >>> >> >> Yes, in the next sentence. >> >> Suppose I have a node whose contents are: >>> >>> from operator import mul >>> >>> def factorial(number): >>> if number < 0: >>> raise ValueError >>> if number == 0: >>> return 1 >>> return reduce(mul, range(number+1), 1) >>> >>> It's a simple function. Imagine this is a helper function that will be >>> used by some other function that interacts with Leo. It is not saved to any >>> file (beyond the .leo file, of course). I would like to create a unit test >>> for this. What is the best way? >>> >> >> There are several ways. >> >> >> *1. Use Python doctests <https://docs.python.org/2/library/doctest.html>* >> >> Here is a tested code: Create a node, @test factorial, whose body is: >> >> import doctest >> from operator import mul >> >> def factorial(number): >> """ >> >>> factorial(5) >> 120 >> """ >> if number < 0: >> raise ValueError >> if number == 0: >> return 1 >> return reduce(mul, range(number+1), 1) >> >> doctest.run_docstring_examples(factorial, globals(), name='factorial') >> >> Execute the code with with Ctrl-B, or with one of the >> run-*-unit-tests-locally commands. >> >> This will fail, for different reasons, on both Python 2 and 3. >> >> *2. Define unit tests using UnitTest.TestCase* >> >> Alternatively, you can define explicit tests. Here is tested code. >> >> import unittest >> from operator import mul >> >> def factorial(number): >> if number < 0: >> raise ValueError >> if number == 0: >> return 1 >> return reduce(mul, range(number+1), 1) >> >> class TestFactorial(unittest.TestCase): >> >> def test1(self): >> self.assertTrue(factorial(5)==120) >> >> suite = unittest.TestLoader().loadTestsFromTestCase(TestFactorial) >> unittest.TextTestRunner(verbosity=1).run(suite) >> >> Again, you can run this with Ctrl-B, or with one of Leo's unit test >> commands. >> >> Edward >> >> -- >> You received this message because you are subscribed to the Google Groups >> "leo-editor" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> Visit this group at https://groups.google.com/group/leo-editor. >> For more options, visit https://groups.google.com/d/optout. >> > -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
