(continued from github - https://github.com/geany/geany/pull/15)
I don't think any of Geany's developers will argue that having some sort of unit testing would be a good idea, especially for the plugin API, but mainly it boils down to:
1) What framework to use (Geany is written in plain C).
From the Stack Overflow question "Is Google Test OK for testing C
code?" (http://stackoverflow.com/a/6218365/304706) :
It is pretty common to test C code using a C++ testing frameworks, even the leading book on the subject (http://pragprog.com/titles/jgade/test-driven-development-for-embedded-c) follows this approach. I have used googletest extensively in the past to unit test C code and can recommend it.
I have written a blog post about it that might be useful: http://meekrosoft.wordpress.com/2009/11/09/unit-testing-c-code-with-the-goog...
...
As long as your headers are C++-compatible (not using C++ keywords, export symbols with correct linkage), it should be fine.
2) How do you run unit tests on a live GUI application with no libraries (surely there's a way).
I don't have much experience, so I can't offer any suggestions. But I can do the research.
3) Who's going to do it :)
If you want to help with this, I'm sure it would be appreciated.
I could help start it off, but it would have to be an on-going thing. I wouldn't have the time to sit down and write tests for the whole application. Each developer could get into the habit of writing a test whenever they change something or add a new feature.
The only real restriction IMO is that it not add any dependencies to the application or build system under normal conditions. For example, it would be a bummer to make Joe Hacker have to install some exotic unit testing framework libraries just to do a `make && make install`.
I totally agree with not adding dependencies under normal conditions, and I don't think that will be an issue if the code is written well. Test-driven development often enforces particular design patterns, so there will probably need to be some refactoring involved.
-------------
To be honest, the real reason that I started talking about unit tests, is because I really need them in order to write a lexer for scintilla. Manual testing for lexers would be a nightmare.
<editor_rant>
Also to be honest, I'm still a little conflicted with regards to gedit vs. geany vs. others. Gedit uses GTKSourceView, which has definitions for many more languages, but their lexers are XML / Regex based. So they're really slow for larger files, and they don't support code folding, which I'm starting to get used to. But their community seems to be a lot bigger, and a little more active. I also experimented with an editor called 'Redcar' which now appears to be the worst of both worlds... It uses GTKSourceView, plus the main editor is written in Ruby... Ruby might be my favorite language, but it's damn slow. So yeah, I've tried everything from vim to Eclipse, but so far, only Geany seems to have the right balance. So I'd like to put in some effort to make this editor better - after all, I'm going to be using it for 8 hours a day.
</editor_rant>
Cheers! Nathan
P.S. The documentation needs to be updated for the 'waf' build system, in quite a few places, including geany-plugins.
Am 30.11.2011 07:36, schrieb Nathan Broadbent:
P.S. The documentation needs to be updated for the 'waf' build system, in quite a few places, including geany-plugins.
I don't refer to other points as I would need to catch up discussion on github before (wth why are we using differnt chanels? can we turn off the github commenting stuff.. its a nightmare)
However, comments like you do above are not very helpful. If there is a mistake inside documentation, which might can happen - no question - we still don't know where and what might be wrong. Please be so kind and point to the place you did found the issue. Comments like this only causes us to re ask you one and another time and also are giving a bad formating of you hint (read: I'm a bit against you change succession idea before I ever see it.... which is not a good starting point)
Cheers, Frank
On 11/29/2011 11:12 PM, Frank Lanitz wrote:
Am 30.11.2011 07:36, schrieb Nathan Broadbent:
P.S. The documentation needs to be updated for the 'waf' build system, in quite a few places, including geany-plugins.
I don't refer to other points as I would need to catch up discussion on github before (wth why are we using differnt chanels? can we turn off the github commenting stuff.. its a nightmare)
It's not a nightmare if you use it. Comments are essential for code review, pull requests and useful for discussion of specific code. You can configure your Github notifications to email you just about everything and you can reply using your email client, if it's too much trouble bouncing between web browser and email client.
Nathan made a pull request, he was told the proper channels (upstream) since it was a Scintilla change, then he asked about testing and was directed to the ML to discuss it. If you aren't able to open your web browser, that pretty much sums up the relevant "discussion" on the pull request comments.
Cheers, Matthew Brush
Am 30.11.2011 08:39, schrieb Matthew Brush:
On 11/29/2011 11:12 PM, Frank Lanitz wrote:
Am 30.11.2011 07:36, schrieb Nathan Broadbent:
P.S. The documentation needs to be updated for the 'waf' build system, in quite a few places, including geany-plugins.
I don't refer to other points as I would need to catch up discussion on github before (wth why are we using differnt chanels? can we turn off the github commenting stuff.. its a nightmare)
It's not a nightmare if you use it. Comments are essential for code review, pull requests and useful for discussion of specific code. You can configure your Github notifications to email you just about everything and you can reply using your email client, if it's too much trouble bouncing between web browser and email client.
I activated things I know of and still got feeling, don't receive everything. E.g. the discussion about Ruby stuff I only received one mail.
Nathan made a pull request, he was told the proper channels (upstream) since it was a Scintilla change, then he asked about testing and was directed to the ML to discuss it. If you aren't able to open your web browser, that pretty much sums up the relevant "discussion" on the pull request comments.
Thanks for writing down conclusion.
Cheers, Frank
Am 30.11.2011 08:39, schrieb Matthew Brush:
On 11/29/2011 11:12 PM, Frank Lanitz wrote:
Am 30.11.2011 07:36, schrieb Nathan Broadbent:
P.S. The documentation needs to be updated for the 'waf' build system, in quite a few places, including geany-plugins.
I don't refer to other points as I would need to catch up discussion on github before (wth why are we using differnt chanels? can we turn off the github commenting stuff.. its a nightmare)
It's not a nightmare if you use it. Comments are essential for code review, pull requests and useful for discussion of specific code. You can configure your Github notifications to email you just about everything and you can reply using your email client, if it's too much trouble bouncing between web browser and email client.
Can new comments on github (perhaps except line-specific ones) forwarded to this or a separate mailing list? Having to remember to always look at github as well is annoying.
Best regards.
Hi,
Sorry about that! I won't change topic in the middle of a thread.
I've figured out why the installation documentation didn't work for me: You pre-generate the 'configure' script and package this when you distribute a release in a tarball, but this configure script isn't checked into the repository. I checked out the source-code from github, but the documentation doesn't mention anything about running './autogen.sh' first. (Sorry, I haven't done much C programming for a while...)
Since the project has moved to Github, more people will be getting the source code straight from the repository. So it might be helpful to replace " $ ./configure " with " $ ./autogen.sh " in the "Autotools based build system" section of the manual (http://www.geany.org/manual/current/#installation), and also in the installation section of the README.
Thanks, Nathan
On Wed, Nov 30, 2011 at 3:12 PM, Frank Lanitz frank@frank.uvena.de wrote:
Am 30.11.2011 07:36, schrieb Nathan Broadbent:
P.S. The documentation needs to be updated for the 'waf' build system, in quite a few places, including geany-plugins.
I don't refer to other points as I would need to catch up discussion on github before (wth why are we using differnt chanels? can we turn off the github commenting stuff.. its a nightmare)
However, comments like you do above are not very helpful. If there is a mistake inside documentation, which might can happen - no question - we still don't know where and what might be wrong. Please be so kind and point to the place you did found the issue. Comments like this only causes us to re ask you one and another time and also are giving a bad formating of you hint (read: I'm a bit against you change succession idea before I ever see it.... which is not a good starting point)
Cheers, Frank _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Wed, Nov 30, 2011 at 7:55 PM, Nathan Broadbent nathan.f77@gmail.com wrote:
Hi,
Sorry about that! I won't change topic in the middle of a thread.
I've figured out why the installation documentation didn't work for me: You pre-generate the 'configure' script and package this when you distribute a release in a tarball, but this configure script isn't checked into the repository.
The configure script shouldn't be checked into the repository as it might not match the target machine.
I checked out the source-code from github, but the documentation doesn't mention anything about running './autogen.sh' first. (Sorry, I haven't done much C programming for a while...)
Good point, that part of the docs were written when Geany was mostly a C programmers paradise, and *every* C programmer sort of understood autofools, now it has so many non-C users the process should be better explained.
Since the project has moved to Github, more people will be getting the source code straight from the repository. So it might be helpful to replace " $ ./configure " with " $ ./autogen.sh " in the "Autotools based build system" section of the manual (http://www.geany.org/manual/current/#installation), and also in the installation section of the README.
Don't suppose you would have a shance to provide a patch/pull request?
Cheers Lex
On 11/30/2011 12:55 AM, Nathan Broadbent wrote:
I've figured out why the installation documentation didn't work for me: You pre-generate the 'configure' script and package this when you distribute a release in a tarball, but this configure script isn't checked into the repository. I checked out the source-code from github, but the documentation doesn't mention anything about running './autogen.sh' first. (Sorry, I haven't done much C programming for a while...)
Since the project has moved to Github, more people will be getting the source code straight from the repository. So it might be helpful to replace " $ ./configure " with " $ ./autogen.sh " in the "Autotools based build system" section of the manual (http://www.geany.org/manual/current/#installation), and also in the installation section of the README.
The ./configure script is automatically generated so it's not so great to check it into the VCS. It is mentioned on the Git page[1] for people who're building development code though. I think the manual is strictly for stable release source code (same with README).
[1] http://www.geany.org/Download/Git
Cheers, Matthew Brush
Am 30.11.2011 10:11, schrieb Matthew Brush:
On 11/30/2011 12:55 AM, Nathan Broadbent wrote:
I've figured out why the installation documentation didn't work for me: You pre-generate the 'configure' script and package this when you distribute a release in a tarball, but this configure script isn't checked into the repository. I checked out the source-code from github, but the documentation doesn't mention anything about running './autogen.sh' first. (Sorry, I haven't done much C programming for a while...)
Since the project has moved to Github, more people will be getting the source code straight from the repository. So it might be helpful to replace " $ ./configure " with " $ ./autogen.sh " in the "Autotools based build system" section of the manual (http://www.geany.org/manual/current/#installation), and also in the installation section of the README.
The ./configure script is automatically generated so it's not so great to check it into the VCS. It is mentioned on the Git page[1] for people who're building development code though. I think the manual is strictly for stable release source code (same with README).
I agree. Maybe we could add a section to HACKING file too as it would fit there IMHO.
Cheers, Frank
[...]
I agree. Maybe we could add a section to HACKING file too as it would fit there IMHO.
Hi Frank,
Since we have a long release cycle lots of non-C speaking people use the Git version, so I think it needs to be where users can see it, not just us developers :)
Cheers Lex
Cheers, Frank
Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Am 30.11.2011 10:24, schrieb Lex Trotman:
[...]
I agree. Maybe we could add a section to HACKING file too as it would fit there IMHO.
Since we have a long release cycle lots of non-C speaking people use the Git version, so I think it needs to be where users can see it, not just us developers :)
My understanding was that HACKING was the README for them. However, maybe we should add a link between both. I don't think we need to refer inside 'release' README to autogen.sh.
Cheers, Frank
Le 30/11/2011 15:24, Frank Lanitz a écrit :
Am 30.11.2011 10:24, schrieb Lex Trotman:
[...]
I agree. Maybe we could add a section to HACKING file too as it would fit there IMHO.
Since we have a long release cycle lots of non-C speaking people use the Git version, so I think it needs to be where users can see it, not just us developers :)
My understanding was that HACKING was the README for them. However, maybe we should add a link between both. I don't think we need to refer inside 'release' README to autogen.sh.
I don't think HACKING is the README for unreleased sources, it's the README for people wanting to modify Geany's sources... but yes, maybe it's supposed to be the same.
However I agree, it makes no sense to tell people with a release tarball to run autogen.sh, since there is *no* autogen on release tarballs. So, maybe we could either add a note in the current HACKING, or add something like a README.git or whatever mentioning the difference with the tarballs?
Cheers, Colomban
On 11/30/2011 09:45 AM, Colomban Wendling wrote:
Le 30/11/2011 15:24, Frank Lanitz a écrit :
Am 30.11.2011 10:24, schrieb Lex Trotman:
[...]
I agree. Maybe we could add a section to HACKING file too as it would fit there IMHO.
Since we have a long release cycle lots of non-C speaking people use the Git version, so I think it needs to be where users can see it, not just us developers :)
My understanding was that HACKING was the README for them. However, maybe we should add a link between both. I don't think we need to refer inside 'release' README to autogen.sh.
I don't think HACKING is the README for unreleased sources, it's the README for people wanting to modify Geany's sources... but yes, maybe it's supposed to be the same.
However I agree, it makes no sense to tell people with a release tarball to run autogen.sh, since there is *no* autogen on release tarballs. So, maybe we could either add a note in the current HACKING, or add something like a README.git or whatever mentioning the difference with the tarballs?
Or maybe a specific README.rst for git(hub) users that doesn't get packaged or released, which would be hard to miss since it'd show up on the repository page (I think it would override the README?). We could have a hyperlink from that file to the full README and HACKING files in git(hub) also.
OTOH, autogen.sh scripts are so common, maybe it's not even worth doing anything extra at all and just leaving the existing instructions on the Git page on geany.org.
Cheers, Matthew Brush
[...]
OTOH, autogen.sh scripts are so common, maybe it's not even worth doing anything extra at all and just leaving the existing instructions on the Git page on geany.org.
Yes I agree, but what Nathan is saying (I think) is that the installation/compiling from source section of the manual should match this.
Cheers Lex
Cheers, Matthew Brush
Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Hi Nathan,
I hope this reply doesn't end up sounding too negative, I even suggested Geany needed unit testing myself once in the past. ... but
On Wed, Nov 30, 2011 at 5:36 PM, Nathan Broadbent nathan.f77@gmail.com wrote: [...]
...
As long as your headers are C++-compatible (not using C++ keywords, export symbols with correct linkage), it should be fine.
All Geany is C, not C++, ie no extern C {} anywhere. Don't know if this is an issue.
2) How do you run unit tests on a live GUI application with no libraries (surely there's a way).
I don't have much experience, so I can't offer any suggestions. But I can do the research.
For unit testing I don't think the GUI thing is such a problem compared to the fact that the sort of application Geany is means that it has *lots* of global state (all the filetypes, all the open documents etc) and setting this up right for unit tests is going to be hard.
3) Who's going to do it :)
If you want to help with this, I'm sure it would be appreciated.
I could help start it off, but it would have to be an on-going thing. I wouldn't have the time to sit down and write tests for the whole application. Each developer could get into the habit of writing a test whenever they change something or add a new feature.
And here lies the biggest problem, for an existing application the added value is small if only changes get tested, and changes become very expensive if a full unit test is required for any unit that is changed. And what are you going to test against? There is no internal specification for Geany's units.
The only real restriction IMO is that it not add any dependencies to the application or build system under normal conditions. For example, it would be a bummer to make Joe Hacker have to install some exotic unit testing framework libraries just to do a `make && make install`.
I totally agree with not adding dependencies under normal conditions, and I don't think that will be an issue if the code is written well. Test-driven development often enforces particular design patterns, so there will probably need to be some refactoring involved.
Test driven development is fine, thats how I do most of my stuff (in C++ with my own test harness and -DWITH_UNIT_TESTS) but retrofitting it to an existing mature application is unlikely to be cost effective.
To be honest, the real reason that I started talking about unit tests, is because I really need them in order to write a lexer for scintilla. Manual testing for lexers would be a nightmare.
I'm unsure what a test harness would gain you, lets use your favourite language Ruby, how would you test such a lexer other than feeding it ruby source and looking at the results? Which is what opening a Ruby file does.
<editor_rant>
[...]
</editor_rant>
Cheers! Nathan
P.S. The documentation needs to be updated for the 'waf' build system, in quite a few places, including geany-plugins.
How?
Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On 11/29/2011 10:36 PM, Nathan Broadbent wrote:
As long as your headers are C++-compatible (not using C++ keywords, export symbols with correct linkage), it should be fine.
At one point, out of curiosity, I tried to make a C++ plugin for Geany and the compiler choked on some keywords (`template` comes to mind, some other too I'm sure). It probably wouldn't be a big deal to make the needed changes though.
- Who's going to do it :)
If you want to help with this, I'm sure it would be appreciated.
I could help start it off, but it would have to be an on-going thing. I wouldn't have the time to sit down and write tests for the whole application. Each developer could get into the habit of writing a test whenever they change something or add a new feature.
Yeah, I meant more with getting it all rigged up in the first place and maybe putting some info on the wiki how to use it.
The only real restriction IMO is that it not add any dependencies to the application or build system under normal conditions. For example, it would be a bummer to make Joe Hacker have to install some exotic unit testing framework libraries just to do a `make&& make install`.
I totally agree with not adding dependencies under normal conditions, and I don't think that will be an issue if the code is written well. Test-driven development often enforces particular design patterns, so there will probably need to be some refactoring involved.
Geany uses a lot of global variables/state, so the individual functions sometimes are pulling in context from the running instance, bypassing function parameters and return values, that would be harder to test probably.
The only way I can see it would actually work - keeping in mind I don't have much experience with unit testing - is that you would have to launch an instance of the GUI and for some functions even simulate mouse clicks or key presses and then read the display pixels or global geany variables/state afterwards and see if it passes the tests.
To be honest, the real reason that I started talking about unit tests, is because I really need them in order to write a lexer for scintilla. Manual testing for lexers would be a nightmare.
That sounds much more approachable than doing it for Geany :)
Cheers, Matthew Brush
Am 30.11.2011 08:17, schrieb Matthew Brush:
To be honest, the real reason that I started talking about unit tests, is because I really need them in order to write a lexer for scintilla. Manual testing for lexers would be a nightmare.
That sounds much more approachable than doing it for Geany :)
Well... Geany in special Geany-Plugin-API needs such thing as well, but starting at Scintilla (given they don't have such a system - I just don't know) would make sense most.
Cheers, Frank