Hi,
I can tests go in the same files as the code.
proc hello(name: string): string =
result = "hello"
result.add name
when TEST:
assert hello "world" == "hello world"
I considering, that it is good way. Do you any best practicies of this feauture?
thanks
For simple stuff, especially for unit testing small modules
when isMainModule:
doAssert #condition#
At the topo of the unittest module documentation it says:
Note: Instead of unittest.nim, please consider to use the testament tool which offers process isolation for your tests. Also when isMainModule: doAssert conditionHere is usually a much simpler solution for testing purposes.
Does that mean that unittest is obsolete and should not be used? The docs do not provide a link to the testament module so the advice is not very actionable :-)
I think for small simple modules it's ok to have the tests (with doAssert, not assert) in the same file. Apart from that, I prefer a test module using the unittest module for each module to test.
In my experience, putting the tests in the same file as the tested code makes maintaining the tests awkward if the tests grow. Consequently, tests aren't as thorough as if put into an extra file. Having the tests in an extra file helps me focus more on writing good tests with good coverage.
Good point. This comes up from time to time in the forum. It would be really nice if there was some documentation on testament (or if there's some, a link to it). Also, I vaguely remember that testament also has disadvantages over unittest, so the tradeoff when to use one or the other should be explained. So far I've used only unittest and like it, but I've written only relatively small programs in Nim.
If the cases where testament is considered the better option are known, it would help to put this information in the paragraph in the unittest documentation. So readers wouldn't be confused about missing out on testament if unittest is fine for their purposes.
In my opinion, it really depends on the the size of your file and the complexity of your procedure. For me, if it's one simple procedure, I guess having it in the file works, and I'd do it the way @shirleyquirk does. But if it's multiple procedures or a complex one, I'd probably separate it out.
For projects, I'd have all the tests in a separate directory. I personally follow the nimble directory layout:
Hope this gives you some insight.
Testing in the same module has the advantage of testing non exported parts of your code. But this is also a problem as you can't test if something is exported.
There is no reason you can't have multiple different types of tests. Have same module testing private details, also have some separate unit tests for the exported aspects of the module as well as integration tests for you whole application.
I wrote a macro so you can test private procedures in a separate file.
https://github.com/flenniken/metar/blob/master/metar/tpub.nim
Testing in the same module has the advantage of testing non exported parts of your code.
You can test "private" APIs if you include the file to test instead of import ing it.
That said, I think it's good to also have tests where the file to test is import ed. Otherwise you could run into the situation that the tests succeed but production code fails because you forgot to make some necessary API public. This is likely not a problem for applications where you eventually import and use the module, but it may be a problem for libraries.