Menu
▾
▴
fofredux-devel
|
From: Kevin <ke...@dr...> - 2005-12-05 03:52:52
|
To help with debugging, I've started writing some unit tests using SimpleTest. I plan on putting them in a subdirectory called "tests". If anyone has any concerns reguarding this, let me know. --Kevin |
|
From: Andrew T. (nilspace) <nil...@us...> - 2005-12-05 04:06:36
|
Only concerned that we haven't done it yet and more often. ;) I think this is an excellent idea. It had crossed my mind, but got pushed back. Thanks for putting this together. I assume we can write tests for all the major functionality: adding, removing, viewing feeds, generated OPML, generated RSS (future feature)? I haven't seen SimpleTest before, I'll make sure to check it out. Andy On 12/4/05, Kevin <ke...@dr...> wrote: > > To help with debugging, I've started writing some unit tests using > SimpleTest. I plan on putting them in a subdirectory called "tests". > If anyone has any concerns reguarding this, let me know. > > --Kevin > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi= les > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick > _______________________________________________ > Fofredux-devel mailing list > Fof...@li... > https://lists.sourceforge.net/lists/listinfo/fofredux-devel > |
|
From: Kevin <ke...@dr...> - 2005-12-05 14:30:44
|
Andrew Turner (nilspace) wrote: >Only concerned that we haven't done it yet and more often. ;) > >I think this is an excellent idea. It had crossed my mind, but got >pushed back. Thanks for putting this together. I assume we can write >tests for all the major functionality: adding, removing, viewing >feeds, generated OPML, generated RSS (future feature)? > > FoFr is a small project, but it can still benefit from unit testing. It makes heavy use of functions to organize the backend code.(see also: "a good thing") This type of code organization makes it easier to test. I figured each fof function will have it's own test case class. I've already created one for fof_content_sanitize(). Question: Should the tests be included in code releases? I don't see the benefit in that. I figure they will just live in the CVS repository for developers to use. >I haven't seen SimpleTest before, I'll make sure to check it out. > > The two choices are SimpleTest and PHPUnit. I've only ever used SimpleTest. I gave the list a heads up in case someone wanted to pipe up with compelling reasons to use PHPUnit instead. If no one has objections, I'll commit what I have. |
|
From: Andrew T. (nilspace) <nil...@us...> - 2005-12-05 16:50:29
|
Well, you could add a new project in the CVS repository - fofredux-test or something similar. Anyone could check out the fofredux project, and devs could subsequently checkout fofredux-test: cvs -d:ext:nil...@cv...:/cvsroot/fofredux co fofredux cvs -d:ext:nil...@cv...:/cvsroot/fofredux co fofredux-test On 12/5/05, Kevin <ke...@dr...> wrote: > Andrew Turner (nilspace) wrote: > > >Only concerned that we haven't done it yet and more often. ;) > > > >I think this is an excellent idea. It had crossed my mind, but got > >pushed back. Thanks for putting this together. I assume we can write > >tests for all the major functionality: adding, removing, viewing > >feeds, generated OPML, generated RSS (future feature)? > > > > > FoFr is a small project, but it can still benefit from unit testing. It > makes heavy use of functions to organize the backend code.(see also: "a > good thing") This type of code organization makes it easier to test. > > I figured each fof function will have it's own test case class. I've > already created one for fof_content_sanitize(). > > Question: Should the tests be included in code releases? I don't see > the benefit in that. I figure they will just live in the CVS repository > for developers to use. > > >I haven't seen SimpleTest before, I'll make sure to check it out. > > > > > The two choices are SimpleTest and PHPUnit. I've only ever used > SimpleTest. I gave the list a heads up in case someone wanted to pipe > up with compelling reasons to use PHPUnit instead. If no one has > objections, I'll commit what I have. > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi= les > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick > _______________________________________________ > Fofredux-devel mailing list > Fof...@li... > https://lists.sourceforge.net/lists/listinfo/fofredux-devel > -- Andrew Turner ajt...@hi... 42.4266N x 83.4931W http://highearthorbit.com Northville, Michigan, USA Photos - http://flickr.com/photos/ajturner Travel - http://highearthorbit.com/projects/location/ |
|
From: Kevin <ke...@dr...> - 2005-12-05 21:58:04
|
> Well, you could add a new project in the CVS repository - > fofredux-test or something similar. Anyone could check out the > fofredux project, and devs could subsequently checkout fofredux-test: > > cvs -d:ext:nil...@cv...:/cvsroot/fofredux co fofredux > cvs -d:ext:nil...@cv...:/cvsroot/fofredux co fofredux-test The unit tests should evolve as the code does. They should be tagged and branched to follow the code that they test. Wouldn't putting the unit tests in their own module hinder this? Writing, running, and maintaining the unit tests should be made as easy a= s possible. Otherwise, they won't get used. That's why my first thought was making it a subdirectory and just excluding it when creating tarballs for release. --=20 Kevin |
|
From: Andrew T. (nilspace) <nil...@us...> - 2005-12-05 22:15:40
|
branching is not a good idea. it doesn't promote keeping them together. Putting them in another directory is the best way to do it then. That way, when we do branch/tag the FoFR code, the tests will also be tagged/branch. Andrew On 12/5/05, Kevin <ke...@dr...> wrote: > > > Well, you could add a new project in the CVS repository - > > fofredux-test or something similar. Anyone could check out the > > fofredux project, and devs could subsequently checkout fofredux-test: > > > > cvs -d:ext:nil...@cv...:/cvsroot/fofredux co fofredux > > cvs -d:ext:nil...@cv...:/cvsroot/fofredux co fofredux-test > > The unit tests should evolve as the code does. They should be tagged and > branched to follow the code that they test. Wouldn't putting the unit > tests in their own module hinder this? > > Writing, running, and maintaining the unit tests should be made as easy a= s > possible. Otherwise, they won't get used. That's why my first thought > was making it a subdirectory and just excluding it when creating tarballs > for release. > > -- > Kevin > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi= les > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_idv37&alloc_id=16865&opclick > _______________________________________________ > Fofredux-devel mailing list > Fof...@li... > https://lists.sourceforge.net/lists/listinfo/fofredux-devel > |
|
From: Kevin <ke...@dr...> - 2005-12-05 23:15:01
|
Agreed. So, I'll go ahead w/ the subdirectory for tests. > branching is not a good idea. it doesn't promote keeping them > together. Putting them in another directory is the best way to do it > then. That way, when we do branch/tag the FoFR code, the tests will > also be tagged/branch. > > Andrew > > On 12/5/05, Kevin <ke...@dr...> wrote: >> >> > Well, you could add a new project in the CVS repository - >> > fofredux-test or something similar. Anyone could check out the >> > fofredux project, and devs could subsequently checkout fofredux-test= : >> > >> > cvs -d:ext:nil...@cv...:/cvsroot/fofredux co fofredux >> > cvs -d:ext:nil...@cv...:/cvsroot/fofredux co fofredux-test >> >> The unit tests should evolve as the code does. They should be tagged >> and >> branched to follow the code that they test. Wouldn't putting the unit >> tests in their own module hinder this? >> >> Writing, running, and maintaining the unit tests should be made as eas= y >> as >> possible. Otherwise, they won't get used. That's why my first though= t >> was making it a subdirectory and just excluding it when creating >> tarballs >> for release. >> >> -- >> Kevin >> >> >> >> ------------------------------------------------------- >> This SF.net email is sponsored by: Splunk Inc. Do you grep through log >> files >> for problems? Stop! Download the new AJAX search engine that makes >> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK= ! >> http://ads.osdn.com/?ad_idv37&alloc_id=16865&opclick >> _______________________________________________ >> Fofredux-devel mailing list >> Fof...@li... >> https://lists.sourceforge.net/lists/listinfo/fofredux-devel >> > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=3Dclick > _______________________________________________ > Fofredux-devel mailing list > Fof...@li... > https://lists.sourceforge.net/lists/listinfo/fofredux-devel > --=20 Kevin |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X