My recommended procedure would be to write to stdout and capture it.
There's no guarantee that we can write to disk. I can add a line on that...
On 26 April 2018 at 12:06, Koes, David wrote:
> Do you want to have a recommended procedure for tests that write files and
> then need to compare them?
Do you want to have a recommended procedure for tests that write files and then
need to compare them? I’m assuming from what you wrote that tests are
automatically run from the tests/files directory and I think you would want to
discourage people from cluttering that directory with output files
Okay, I think it's close to completion. Again, comments welcome...
https://gist.github.com/baoilleach/d9f02fb906e70277f6b4721d63d68b59
- Noel
On 25 April 2018 at 13:50, David Koes wrote:
> Missing description of OB_COMPARE (and other asserts?). Is the idea of
> OB_REQUIRE that it should be us
Missing description of OB_COMPARE (and other asserts?). Is the idea of OB_REQUIRE that it should be used for checks
that would indicate there is something wrong with the overall test harness because it will end _all_ tests, not the
current one?
Could give one sentence description of run_exec (
(Sorry - previous email was sent by accident)
On the topic of documentation, here's what I've got so far:
https://gist.github.com/baoilleach/d9f02fb906e70277f6b4721d63d68b59
I still need to add descriptions of how to specify testfiles, and handle
exceptions. Apart from that, anything missing or c
On the topic of documentation, here's what I've got so far. Anything
missing?
On 17 April 2018 at 06:58, David van der Spoel wrote:
> Den 2018-04-17 kl. 07:51, skrev Noel O'Boyle:
>
>> To avoid digressing, absolutely we would like to do this and have the
>> technical means to enforce...once we r
Den 2018-04-17 kl. 07:51, skrev Noel O'Boyle:
To avoid digressing, absolutely we would like to do this and have the
technical means to enforce...once we reduce the warnings. I did a
certain amount already this year. Once a particular type of warning is
eliminated we can add it as a requirement
To avoid digressing, absolutely we would like to do this and have the
technical means to enforce...once we reduce the warnings. I did a certain
amount already this year. Once a particular type of warning is eliminated
we can add it as a requirement using gcc's treat warnings as errors. But
we're no
Den 2018-04-16 kl. 22:46, skrev Dominik 'Rathann' Mierzejewski:
On Monday, 16 April 2018 at 20:20, David van der Spoel wrote:
Den 2018-04-16 kl. 17:36, skrev David Koes:
I didn't chime in since I thought it was obviously a good idea.
However, I strongly agree that the process of creating a test
On Monday, 16 April 2018 at 20:20, David van der Spoel wrote:
> Den 2018-04-16 kl. 17:36, skrev David Koes:
> > I didn't chime in since I thought it was obviously a good idea.
> > However, I strongly agree that the process of creating a test case needs
> > to be as simple and documented as possible
On Monday, 16 April 2018 at 21:59, Geoffrey Hutchison wrote:
[...]
> Keep in mind many (most?) of the warnings are from the InChI code
> - which isn't something we want to mess with.
Fixes for warnings in InChI should be sent upstream, to
inchi-disc...@lists.sourceforge.net .
Regards,
Dominik
--
> How about making warning-free code a must?
> Whenever I compile OB I get tons of warnings of potentially serious character.
Patches that reduce/fix warnings are always accepted. :-) Julien Nabet
(serval2412) has contributed *many* such patches.
Keep in mind many (most?) of the warnings are fro
Den 2018-04-16 kl. 17:36, skrev David Koes:
I didn't chime in since I thought it was obviously a good idea.
However, I strongly agree that the process of creating a test case needs
to be as simple and documented as possible. I had a test case with my
last pull request, but it required a fair
I didn't chime in since I thought it was obviously a good idea. However, I strongly agree that the process of creating
a test case needs to be as simple and documented as possible. I had a test case with my last pull request, but it
required a fair amount of poking around to figure out how to b
I'm disappointed in the lack of support for this. David Koes - you
suggested a GSoc on this topic, for example. Anyway, for my part, I will
write up info on adding testcases, but also start to nudge PR submitters
towards including testcases.
Regards,
- Noel
On 3 April 2018 at 13:15, Noel O'Boyl
Noted. We will do this. In fact, I commit to doing this whether or not this
proposal goes ahead.
- Noel
On 3 April 2018 at 11:54, David Hall wrote:
> I mostly agree, but I’ll mention the big hurdle I came across the first
> time I wrote a test for openbabel.
>
> Many times, one comes across a b
I mostly agree, but I’ll mention the big hurdle I came across the first time I
wrote a test for openbabel.
Many times, one comes across a bug when using the command line tools, e.g.
obabel , so debugging and testing goes through using that program.
I think (correct if I’m wrong), the easiest wa
Hi all,
Very few PRs come with test cases. Basically, we just don't know if any of
them do what they say, and even if they do, they probably will bit rot at a
future date due to other PRs. The irony is that the person who wrote the
code clearly tested it (one would assume) - but just didn't check
18 matches
Mail list logo