Re: Unit testing

. It includes gtest-1.7.0 (permitted by the license). Hi Vincent, What is the difference with the tests we current use (I mean the "make check" sort). The same but with better interface? gtest is about unit testing. Current test framework from Georg is more about Blackbox testing. In my

Re: Unit testing

On 04/11/2015 14:30, Vincent van Ravesteijn wrote: However, I would also count as advantage, if there is someone familiar with the framework and willing to do the setup and lend a helping hand to others. (Maybe, the toolkit with the most developers willing to work on should win.) We have

Re: Unit testing

> If there is no known advantage of gtest, I suggest using one of > boost::test or QTest, as these come from sources we already rely on. > The major advantage of "gtest" is that I only have to type "git push" and we have the framework up and running. A downside of boost::test is, according

Re: Unit testing

On 2015-11-03, Georg Baum wrote: > Vincent van Ravesteijn wrote: >> On Tue, Nov 3, 2015 at 2:28 PM, Jean-Marc Lasgouttes >> wrote: > Regarding the test framework there is also boost::test (which would fit our > needs as well). Unfortunately I have neither experience with

Re: Unit testing

Le 02/11/2015 21:36, Vincent van Ravesteijn a écrit : Dear all, I have prepared a unit test framework based on google-test (gtest). You can see the commits at http://git.lyx.org/?p=developers/vfr/lyx.git;a=shortlog;h=refs/heads/tests. It includes gtest-1.7.0 (permitted by the license). Hi

Re: Unit testing

>> Any comments ? Shall I proceed to push this to master ? >> >> Vincent >> > > Having a unit test framework integrated is a very good idea! > > Why have you chosen gtest and not QTest? Does gtest has interesting > features which QTest does not have? I'm not

Re: Unit testing

testing can be enabled by running CMake with -DLYX_ENABLE_UNIT_TESTS. This will make a target gtest-main and unit-tests. It also create LyX.lib against which the unit testing executable is linked so that the functionality in the core can be tested. I have created a first (example) test case

Re: Unit testing

Vincent van Ravesteijn wrote: > On Tue, Nov 3, 2015 at 2:28 PM, Jean-Marc Lasgouttes > wrote: >> >> Hi Vincent, >> >> What is the difference with the tests we current use (I mean the "make >> check" sort). The same but with better interface? The overhead to add a test with

Re: Unit testing

On Tue, Nov 3, 2015 at 2:28 PM, Jean-Marc Lasgouttes wrote: > Le 02/11/2015 21:36, Vincent van Ravesteijn a écrit : >> >> Dear all, >> >> I have prepared a unit test framework based on google-test (gtest). You >> can see the commits at >> >>

Unit testing

Dear all, I have prepared a unit test framework based on google-test (gtest). You can see the commits at http://git.lyx.org/?p=developers/vfr/lyx.git;a=shortlog;h=refs/heads/tests. It includes gtest-1.7.0 (permitted by the license). Unit testing can be enabled by running CMake

Re: LyX unit testing

Op 19-9-2013 8:37, Hashini Senaratne schreef: Hello Vincent, But in general, I would like to introduce unit testing, yes. Currently, is there any guide that I can follow, how the suggested testframe work can be set to the LyX environment? Thanks Hashini Hi Hashini, I'm not sure what

Re: LyX unit testing

Op 19-9-2013 8:37, Hashini Senaratne schreef: Hello Vincent, But in general, I would like to introduce unit testing, yes. Currently, is there any guide that I can follow, how the suggested testframe work can be set to the LyX environment? Thanks Hashini Hi Hashini, I'm not sure what

Re: LyX unit testing

Hello Vincent, But in general, I would like to introduce unit testing, yes. Currently, is there any guide that I can follow, how the suggested testframe work can be set to the LyX environment? Thanks Hashini

Re: LyX unit testing

Hello Vincent, > But in general, I would like to introduce unit testing, yes. > Currently, is there any guide that I can follow, how the suggested testframe work can be set to the LyX environment? Thanks Hashini

Re: LyX unit testing

in some large classe, etc. But in general, I would like to introduce unit testing, yes. Vincent Vincent

Re: LyX unit testing

be nice to get feedback from others. How much of a burden would introducing this framework be for the developers that aren't interested in unit testing? Would their workflow have to change or could they just ignore everything to do with unit testing if they want? Lastly, there are huge problems

Re: LyX unit testing

in some large classe, etc. But in general, I would like to introduce unit testing, yes. Vincent Vincent

Re: LyX unit testing

k > at all ? I have only researched the google-test framework briefly but it looks nice. I don't write much of the core code though so it would be nice to get feedback from others. How much of a burden would introducing this framework be for the developers that aren't interested in unit testing

LyX unit testing

Hi Vincent, Do you have any plans to merge the gtest code http://git.lyx.org/?p=developers/vfr/lyx.git;a=shortlog;h=refs/heads/tests into master after the 2.1 release? Does it still need a lot of work before it should be merged? Hashini has expressed interest in implementing unit tests, and a

LyX unit testing

Hi Vincent, Do you have any plans to merge the gtest code http://git.lyx.org/?p=developers/vfr/lyx.git;a=shortlog;h=refs/heads/tests into master after the 2.1 release? Does it still need a lot of work before it should be merged? Hashini has expressed interest in implementing unit tests, and a

Re: Unit testing: The Small Plan

On Wed, May 8, 2013 at 2:59 AM, Elmar Hinz t3el...@googlemail.com wrote: To get started, I would need to do some more simple cases first. Hi Elmar, Did you make any progress on this? I know little about unit tests so I won't be able to help much here, but I'm interested in any progress you

Re: Unit testing: The Small Plan

On Wed, May 8, 2013 at 2:59 AM, Elmar Hinz wrote: > To get started, I would need to do some more simple cases first. Hi Elmar, Did you make any progress on this? I know little about unit tests so I won't be able to help much here, but I'm interested in any progress you

Re: Unit testing: The Small Plan

for existing software, is much more difficult. In the beginning that are extra costs. They pay on the long run by fewer bugs. I have to weight. For user-driven actions (LFUNs), LyX already has a test framework. However, these tests do not cover internals of LyX. Right, unit testing is only one class

Re: Unit testing: The Small Plan

ly 100%, without extra costs, as I need to run the code anyway. Writing tests for existing software, is much more difficult. In the beginning that are extra costs. They pay on the long run by fewer bugs. I have to weight. > For user-driven actions (LFUNs), LyX already has a test framework. >

Unit testing: The Small Plan

Hello list, I'd like to come up with a small plan for getting started with unit testing: == 1.) Directory structure: tests/unit/ == * Unit tests stay their own directory separated from src/. * Below tests/unit the directory structure mirrors

Re: Unit testing: The Small Plan

On 05/07/2013 04:57 AM, Elmar Hinz wrote: Hello list, I'd like to come up with a small plan for getting started with unit testing: I am a total ignoramus when it comes to unit testing, so I will leave it to others who actually know something to express a view. Richard

Re: Unit testing: The Small Plan

Elmar Hinz wrote: If somebody can give improvements to the plan, it's welcome. I guess people will let you do almost anything what you like in test/* but they will become much more picky when it comes to changes in src/. Perhaps the best way is to try example, post patch here and and look what

Re: Unit testing: The Small Plan

Op 7-5-2013 10:57, Elmar Hinz schreef: Hello list, I'd like to come up with a small plan for getting started with unit testing: I would like to see some examples of mocking and injection. I tried to write some tests using the google framework, and started with the Buffer class

Re: Unit testing: The Small Plan

On Tue, May 7, 2013 at 9:20 PM, Pavel Sanda sa...@lyx.org wrote: Elmar Hinz wrote: If somebody can give improvements to the plan, it's welcome. I guess people will let you do almost anything what you like in test/* but they will become much more picky when it comes to changes in src/.

Re: Unit testing: The Small Plan

I would like to see some examples of mocking and injection. Thank you, Vincent, I tried to write some tests using the google framework, and started with the Buffer class. This immediately gives you the problem that it is dependent on a large number of other classes. So, this would mean

Re: Unit testing: The Small Plan

Ideally, one would not need to care about private variables because we are only interested in that the public interface does what it is supposed to do. Right ? Yes, at least as far as it concerns the testing. Denpendency Injection has other aspects. As an example, if there is a class that

Re: Unit testing: The Small Plan

started with unit testing: == 1.) Directory structure: tests/unit/ == * Unit tests stay their own directory separated from src/. * Below tests/unit the directory structure mirrors the structure of src/. * The reason for the subfolder unit is, that unit

Unit testing: The Small Plan

Hello list, I'd like to come up with a small plan for getting started with unit testing: == 1.) Directory structure: "tests/unit/" == * Unit tests stay their own directory separated from src/. * Below "tests/unit" the directo

Re: Unit testing: The Small Plan

On 05/07/2013 04:57 AM, Elmar Hinz wrote: Hello list, I'd like to come up with a small plan for getting started with unit testing: I am a total ignoramus when it comes to unit testing, so I will leave it to others who actually know something to express a view. Richard

Re: Unit testing: The Small Plan

Elmar Hinz wrote: > If somebody can give improvements to the plan, it's welcome. I guess people will let you do almost anything what you like in test/* but they will become much more picky when it comes to changes in src/. Perhaps the best way is to try example, post patch here and and look what

Re: Unit testing: The Small Plan

Op 7-5-2013 10:57, Elmar Hinz schreef: Hello list, I'd like to come up with a small plan for getting started with unit testing: I would like to see some examples of mocking and injection. I tried to write some tests using the google framework, and started with the Buffer class

Re: Unit testing: The Small Plan

On Tue, May 7, 2013 at 9:20 PM, Pavel Sanda wrote: > Elmar Hinz wrote: > > If somebody can give improvements to the plan, it's welcome. > > I guess people will let you do almost anything what you like in test/* > but they will become much more picky when it comes to changes in

Re: Unit testing: The Small Plan

> I would like to see some examples of mocking and injection. > > Thank you, Vincent, > I tried to write some tests using the google framework, and started with > the Buffer class. This immediately gives you the problem that it is > dependent on a large number of other classes. So, this would

Re: Unit testing: The Small Plan

> Ideally, one would not need to care about private variables because we are only interested in that the public interface does what it is supposed to do. Right ? Yes, at least as far as it concerns the testing. Denpendency Injection has other aspects. As an example, if there is a class that

Re: Unit testing: The Small Plan

all plan for getting started with unit testing: == 1.) Directory structure: "tests/unit/" == * Unit tests stay their own directory separated from src/. * Below "tests/unit" the directory structure mirrors the structure of &quo

Re: Unit-Testing

Allan Rae [EMAIL PROTECTED] writes: | Okay so we have a situation where different implementations of std::string | may return different sizes. The ones that don't allow '\0' chars is bogus. The ones that only count until the first '\0' is met is bogus. | I haven't got an STL reference handy

Re: Unit-Testing

Allan Rae <[EMAIL PROTECTED]> writes: | Okay so we have a situation where different implementations of std::string | may return different sizes. The ones that don't allow '\0' chars is bogus. The ones that only count until the first '\0' is met is bogus. | I haven't got an STL reference handy

Re: Unit-Testing

On 10 Oct 1999, Lars Gullik Bjønnes wrote: Allan Rae [EMAIL PROTECTED] writes: | the new strand yet but I already have some doubts about the recent removal | of one of those tests. That test was completely bogus, since it demanded that a std::string cannont contain '\0', so the test had

Re: Unit-Testing

On 10 Oct 1999, Lars Gullik Bjønnes wrote: > Allan Rae <[EMAIL PROTECTED]> writes: > > | the new strand yet but I already have some doubts about the recent removal > | of one of those tests. > > That test was completely bogus, since it demanded that a std::string > cannont contain '\0', so the

Re: Unit-Testing

Allan Rae [EMAIL PROTECTED] writes: | the new strand yet but I already have some doubts about the recent removal | of one of those tests. That test was completely bogus, since it demanded that a std::string cannont contain '\0', so the test had to go. Lgb

Re: Unit-Testing

Allan Rae <[EMAIL PROTECTED]> writes: | the new strand yet but I already have some doubts about the recent removal | of one of those tests. That test was completely bogus, since it demanded that a std::string cannont contain '\0', so the test had to go. Lgb

Re: Unit-Testing

On Thu, Oct 07, 1999 at 07:19:27PM +0200, Lars Gullik Bjønnes wrote: Allan Rae [EMAIL PROTECTED] writes: | Unit-testing is certainly a good thing -- tests all those promises the | code makes and keeps Arndt happy about programming by contract since the | interface can't change without

Re: Unit-Testing

On Thu, Oct 07, 1999 at 08:47:31PM +0200, Asger K. Alstrup Nielsen wrote: Instead, it's much better to simply address each file in order, document the header file, rename functions and variables to have better names, in general clean it up, and try to make things better small piece by

Re: Unit-Testing

On Thu, Oct 07, 1999 at 08:47:31PM +0200, Asger K. Alstrup Nielsen wrote: Instead, it's much better to simply address each file in order, document the header file, rename functions and variables to have better names, in general clean it up, and try to make things better small piece by

Re: Unit-Testing

On Thu, Oct 07, 1999 at 05:25:36PM +0100, Arnd Hanses wrote: Else we would found the 'HardCore testing LyX never come to terms gang', making Core Developers live impossible. Then the real testing experts can by and by implement the rest on their own account and risk and report the

Re: Unit-Testing

Well, it seems that everyone thinks unit testing is a nice thing, but nobody has the time to do it. -- John Weiss

Re: Unit-Testing

On Fri, 8 Oct 1999, John Weiss wrote: On Thu, Oct 07, 1999 at 07:19:27PM +0200, Lars Gullik Bjønnes wrote: Allan Rae [EMAIL PROTECTED] writes: | Unit-testing is certainly a good thing -- tests all those promises the | code makes and keeps Arndt happy about programming by contract since

Re: Unit-Testing

On Thu, Oct 07, 1999 at 07:19:27PM +0200, Lars Gullik Bjønnes wrote: > Allan Rae <[EMAIL PROTECTED]> writes: > > | Unit-testing is certainly a good thing -- tests all those promises the > | code makes and keeps Arndt happy about programming by contract since the > | i

Re: Unit-Testing

On Thu, Oct 07, 1999 at 08:47:31PM +0200, Asger K. Alstrup Nielsen wrote: > Instead, it's much better to simply address each file in order, > document the header file, rename functions and variables to have > better names, in general clean it up, and try to make things better > small piece by

Re: Unit-Testing

On Thu, Oct 07, 1999 at 08:47:31PM +0200, Asger K. Alstrup Nielsen wrote: > Instead, it's much better to simply address each file in order, > document the header file, rename functions and variables to have > better names, in general clean it up, and try to make things better > small piece by

Re: Unit-Testing

On Thu, Oct 07, 1999 at 05:25:36PM +0100, Arnd Hanses wrote: > > Else we would found the 'HardCore testing LyX never come to terms > gang', making Core Developers live impossible. > > Then the real testing experts can by and by implement the rest on their > own account and risk and report the

Re: Unit-Testing

Well, it seems that everyone thinks unit testing is a nice thing, but nobody has the time to do it. -- John Weiss

Re: Unit-Testing

On Fri, 8 Oct 1999, John Weiss wrote: > On Thu, Oct 07, 1999 at 07:19:27PM +0200, Lars Gullik Bjønnes wrote: > > Allan Rae <[EMAIL PROTECTED]> writes: > > > > | Unit-testing is certainly a good thing -- tests all those promises the > > | code makes and ke

Re: Unit-Testing

On Thu, 7 Oct 1999 15:47:30 +1000 (GMT+1000), Allan Rae wrote: Unit-testing is certainly a good thing -- tests all those promises the code makes and keeps Arndt happy about programming by contract since the interface can't change without everybody finding out. I've learned my suggestions

Re: Unit-Testing

Allan Rae [EMAIL PROTECTED] writes: | Unit-testing is certainly a good thing -- tests all those promises the | code makes and keeps Arndt happy about programming by contract since the | interface can't change without everybody finding out. Unit-testing and independant modules is easy

Re: Unit-Testing

Unit-testing and independant modules is easy...unfortunately most of the modules in LyX depends on a multitude of other mudules makeing unit-testing very cumbersome and a lot of additional work. modules in the support dir could easily benefit form unit testing...but it is a lot of work

Re: Unit-Testing

On Thu, 7 Oct 1999 15:47:30 +1000 (GMT+1000), Allan Rae wrote: > >Unit-testing is certainly a good thing -- tests all those promises the >code makes and keeps Arndt happy about programming by contract since the >interface can't change without everybody finding out. I've learned my

Re: Unit-Testing

Allan Rae <[EMAIL PROTECTED]> writes: | Unit-testing is certainly a good thing -- tests all those promises the | code makes and keeps Arndt happy about programming by contract since the | interface can't change without everybody finding out. Unit-testing and independant modules i

Re: Unit-Testing

> Unit-testing and independant modules is easy...unfortunately most of > the modules in LyX depends on a multitude of other mudules makeing > unit-testing very cumbersome and a lot of additional work. > > modules in the support dir could easily benefit form unit > testing

Unit-Testing

[I've been meaning to mention this for some time now. But I've been eaten alive by my house, and have been spending my train rides lately hacking together new emacs programming modes.] At work, just about every library has its own set of unit-tests. If you've never heard of a unit-test, the

Re: Unit-Testing

not sure how well it would work on components of a project rather than an entire project. Do you have any suggestions for other tools to provide automated support for unit-testing? After all, programmers are lazy and if we have to do extra work just to get the testing done then we probably won't

Unit-Testing

[I've been meaning to mention this for some time now. But I've been eaten alive by my house, and have been spending my train rides lately hacking together new emacs programming modes.] At work, just about every library has its own set of unit-tests. If you've never heard of a unit-test, the

Re: Unit-Testing

le tool to support this but I'm not sure how well it would work on components of a project rather than an entire project. Do you have any suggestions for other tools to provide automated support for unit-testing? After all, programmers are lazy and if we have to do extra work just to get the testing don