Bugzilla – Full Text Bug Listing
| Summary: | Improve and create JUnit tests for Changelog GNU formatter | ||
|---|---|---|---|
| Product: | [Tools] Linux Tools | Reporter: | Phil Muldoon <pmuldoon> |
| Component: | ChangeLog | Assignee: | Phil Muldoon <pmuldoon> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | akurtakov, jjohnstn, linux.changelog-inbox, overholt, peter.liu, sgehwolf |
| Version: | unspecified | Keywords: | helpwanted |
| Target Milestone: | 0.8.0 | ||
| Hardware: | PC | ||
| OS: | Linux-GTK | ||
| Whiteboard: | |||
|
Description
Phil Muldoon
Should we schedule this for sometime before Linux Distros 1.0? Let's see if we can get some tests written for 0.2. Hi, Phil and Andrew. I would like to work on this bug issue. Could you provide me some additional information to get me started? I would like to reproduce the bug first and inspect some existing JUnit tests related to this issue. Thanks. Peter. (In reply to comment #3) > Hi, Phil and Andrew. > > I would like to work on this bug issue. Could you provide me some additional > information to get me started? I would like to reproduce the bug first and > inspect some existing JUnit tests related to this issue. Thanks. > > Peter. Peter, This isn't so much a particular bug to be reproduced. The GNU format of a ChangeLog entry isn't documented. It isn't clear what a valid entry should look like. The GNU Format is provided as a default ChangeLog Format Contributor extension. The editor behaviour is provided by a ChangeLog Editor Contributor of which there is also a default GNU version. Documenting both of these needs to be done. Then there is the issue that there are no tests that verify this behaviour. If you want to tackle this, I suggest you start by using the ChangeLog plugin editor in conjunction with looking at its source code. Check out the ChangeLog plugins from the Linux tools repository: svn co http://dev.eclipse.org/svnroot/technology/org.eclipse.linuxtools/changelog/trunk The default GNU formatter extension is found in the org.eclipse.linuxtools.changelog.core plugin src directory under the org.eclipse.linuxtools.changelog.core.formatters package. There you will find the file: GNUFormat.java. There is also the GNU editor contributor that you will find under the org.eclipse.linuxtools.changelog.core.editors package that affect how the entry is parsed and colourized. What you need to start with is to document the current behaviour of the GNU Formatter/Editor contributors with respect to the end-user. 1. What does a GNU formatted entry look like? 2. Are there alternatives/restrictions? 3. What colourization/features are performed in the editor? You can document the results online by editing the Wiki User Guide documentation for ChangeLog. This wiki page is used to create the Eclipse Help documentation. I would suggest adding a new GNU Format section which details what the GNU contributions provide. To edit the wiki, you need to have an Eclipse account id. The wiki is found at: http://wiki.eclipse.org/Linux_Tools_Project/ChangeLog/User_Guide You can upload sample screen snapshots as required. It's fairly straightforward when you look at the existing source for the page. Once the expected behaviour is documented, you can start to design tests that verifies the behaviour. Even though you are basing the test on existing observations, the tests will prevent regressions from occurring unnoticed in the future. For example, if the date line is supposed to be date name <email-address> and is expected to have white-space between each field, you can write a test that has multiple spaces, tabs, etc.. between. You can additionally verify the colourization is correct for this line or you can verify what the Format command in the editor will do to such a line. In some cases, you might have to open bugs. For example, if the editor colourizes correctly with 5 spaces in-between but not 6, this is likely a bug rather than a feature. Writing the first test of a particular set is usually the most difficult because you have to figure out how to invoke this without UI. For example, checking colourization can be done by calling the editor parser directly and evaluating resultant tokens. We can discuss this in more detail when you get to the JUnit test phase. Note that by "Eclipse account id." Jeff means an Eclipse bugzilla account. I'm working on a unit test for the GNU formatter. I'll propose a patch once it's ready :) (In reply to comment #6) > I'm working on a unit test for the GNU formatter. I'll propose a patch once > it's ready :) GNUFormatTest.java is now in trunk as part of the changelog.tests plug-in (Revision 27047). Closing the bug as we have a test now. |