Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #138153 > unrolled thread

Unit test in C and breaking dependencies

Back to article view | Back to comp.lang.c

Contents

  Unit test in C and breaking dependencies pozz <pozzugno@gmail.com> - 2018-11-20 14:22 +0100
    Re: Unit test in C and breaking dependencies James Kuyper <jameskuyper@alumni.caltech.edu> - 2018-11-20 09:07 -0500
    Re: Unit test in C and breaking dependencies Thiago Adams <thiago.adams@gmail.com> - 2018-11-21 04:38 -0800
      Re: Unit test in C and breaking dependencies Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-11-21 12:59 +0000
        Re: Unit test in C and breaking dependencies Thiago Adams <thiago.adams@gmail.com> - 2018-11-21 05:35 -0800
          Re: Unit test in C and breaking dependencies Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-11-21 20:50 +0000
            Re: Unit test in C and breaking dependencies Thiago Adams <thiago.adams@gmail.com> - 2018-11-22 04:10 -0800
              Re: Unit test in C and breaking dependencies Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-11-22 15:30 +0300
                Re: Unit test in C and breaking dependencies Thiago Adams <thiago.adams@gmail.com> - 2018-11-22 04:44 -0800
              Re: Unit test in C and breaking dependencies Thiago Adams <thiago.adams@gmail.com> - 2018-11-22 04:35 -0800
              Re: Unit test in C and breaking dependencies Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-11-22 17:08 +0000
                Re: Unit test in C and breaking dependencies Thiago Adams <thiago.adams@gmail.com> - 2018-11-23 03:08 -0800
                  Re: Unit test in C and breaking dependencies Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-11-24 05:51 +0000
                    Re: Unit test in C and breaking dependencies Chad <cdalten@gmail.com> - 2018-11-24 03:35 -0800
                      Re: Unit test in C and breaking dependencies Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-11-24 12:50 +0000
                        Re: Unit test in C and breaking dependencies Chad <cdalten@gmail.com> - 2018-11-26 07:20 -0800
                          Re: Unit test in C and breaking dependencies Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-11-27 14:32 +0000
                            Re: Unit test in C and breaking dependencies Ian Collins <ian-news@hotmail.com> - 2018-11-28 15:18 +1300
              Re: Unit test in C and breaking dependencies Thiago Adams <thiago.adams@gmail.com> - 2018-11-29 09:16 -0800
          Re: Unit test in C and breaking dependencies Wouter Verhelst <w@uter.be> - 2018-11-23 09:21 +0100
            Re: Unit test in C and breaking dependencies Thiago Adams <thiago.adams@gmail.com> - 2018-11-23 03:16 -0800
              Re: Unit test in C and breaking dependencies Thiago Adams <thiago.adams@gmail.com> - 2018-11-23 03:18 -0800
              Re: Unit test in C and breaking dependencies Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-11-23 15:27 +0300
                Re: Unit test in C and breaking dependencies Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-11-23 06:42 -0800
    Re: Unit test in C and breaking dependencies Ian Collins <ian-news@hotmail.com> - 2018-11-28 15:24 +1300

Page 2 of 2 — ← Prev page 1 [2]

#138201

On Friday, November 23, 2018 at 6:23:41 AM UTC-2, Wouter Verhelst wrote:
> On 21/11/18 14:35, Thiago Adams wrote:
> > On Wednesday, November 21, 2018 at 11:00:02 AM UTC-2, Jorgen Grahn wrote:
> >> On Wed, 2018-11-21, Thiago Adams wrote:
> >>> On Tuesday, November 20, 2018 at 11:22:30 AM UTC-2, pozz wrote:
> >>>> I couldn't understand if the module under test is compiler two times: 
> >>>> one for production code and the other for the test. I think it would be 
> >>>> better to compile it only one time, for production code *and* tests. So 
> >>>> you are sure you are testing the code that really will be in production.
> >>>>
> >>>> So I think it should be better to link the test executable with the same 
> >>>> object files generated during normal build for production code.
> >>>> One suggestion I read is to create a static library with all object 
> >>>> files. The production executable and test executable are created linking 
> >>>> this static library.
> >>>>
> >>>> This approach can be used to break and replace dependecies of a module 
> >>>> under test. Indeed, if you specify the test doubles (replacing modules) 
> >>>> before static library to the linker, it will use the test doubles 
> >>>> instead of real modules.
> >>>>
> >>>> Is it your preferred method? Are there other better ways?
> >>>
> >>> Libraries are bad to maintain in my experience.
> >>> So between recompile or use libraries I prefer recompile.
> >>
> >> This thread confuses me.  A static library, within a project, is just
> >> a container for object files.  Nothing more. Using one makes my
> >> Makefile easier to read and maintain, and I believe it also speeds up
> >> linking the executable.  But it's orthogonal to what you guys are
> >> writing about.
> >>
> > 
> > I answered this:
> > 
> > "I couldn't understand if the module under test is compiler two times: 
> > one for production code and the other for the test."
> > 
> > I think pozz is trying to reuse compilation of libraries 
> > in production and unit test.
> > 
> > I think unit tests are much more granular than
> > libraries. If you have a file1.c and file1.h that doesn't 
> > depends on any other file you can have a unit test just
> > for file1.c. 
> > 
> > Having a library just for file1, file2 .. would 
> > be hard do maintain.
> 
> I'm not sure why you believe that, but it does not match my experience.
> A library is just another target. If it's a shared library you have to
> keep track of the ABI (which is a bit involved), but for a static
> library? Nope.
> 
> > Even not using libraries is something
> > hard to maintain because we need to create makefiles for each 
> > unit test.
> 
> No you don't. You just create multiple targets in the same makefile.
> Additionally, you can (but don't have to) create a single target that
> depends on all the individual unit test builds, and then runs them --
> but that isn't strictly necessary, of course.

The property I want to archive is to move the unit test
easily together with the 'modules' in a sense of reusable
component.
This also makes clear the logic boundaries of the code. The
unit test also works as a presentation about the data 
structures and it's algorithms.

Having everything inside the makefile then I would need
to copy parts of this makefile to another makefile in the
other project. Is that right?

Considering I want something separated, then I think I would
have to create many makefiles. Right? (This is the case
were the modules proposal from the other topic could help)

[toc] | [prev] | [next] | [standalone]

#138202

On Friday, November 23, 2018 at 9:16:30 AM UTC-2, Thiago Adams wrote:
[...]
> The property I want to archive..

Oops..
The property I want to achieve...

[toc] | [prev] | [next] | [standalone]

#138203

Thiago Adams:

>The property I want to archive is to move the unit test
>easily together with the 'modules' in a sense of reusable
>component.  This also makes clear the logic boundaries of
>the code. The unit test also works as a presentation about
>the data structures and it's algorithms.
>
>Having everything inside the makefile then I would need to
>copy parts of this makefile to another makefile in the
>other project. Is that right?
>
>Considering I want something separated, then I think I
>would have to create many makefiles. Right? (This is the
>case were the modules proposal from the other topic could
>help)

I think so.  You can implement your library in library.h and
library.c, and reference it from test program library_test.c
by including library.h .

-- 
()  ascii ribbon campaign - against html e-mail
/\  http://preview.tinyurl.com/qcy6mjc [archived]

[toc] | [prev] | [next] | [standalone]

#138204

On Friday, November 23, 2018 at 12:27:55 PM UTC, Anton Shepelev wrote:
> Thiago Adams:
> 
> >The property I want to archive is to move the unit test
> >easily together with the 'modules' in a sense of reusable
> >component.  This also makes clear the logic boundaries of
> >the code. The unit test also works as a presentation about
> >the data structures and it's algorithms.
> >
> >Having everything inside the makefile then I would need to
> >copy parts of this makefile to another makefile in the
> >other project. Is that right?
> >
> >Considering I want something separated, then I think I
> >would have to create many makefiles. Right? (This is the
> >case were the modules proposal from the other topic could
> >help)
> 
> I think so.  You can implement your library in library.h and
> library.c, and reference it from test program library_test.c
> by including library.h .
> 
Then you set up the makefile with two targets, just to make the
library and to make the test executable. The test executable
may have dependencies that the library does not - the library
might not do any IO, for example, whilst the tests to be useful
must output some results.

[toc] | [prev] | [next] | [standalone]

#138334

On 21/11/2018 02:22, pozz wrote:
> I couldn't understand if the module under test is compiler two times:
> one for production code and the other for the test. I think it would be
> better to compile it only one time, for production code *and* tests. So
> you are sure you are testing the code that really will be in production.

Why wouldn't the code that really be in production?  Unit tests test 
logic, not target specific behaviour.

> So I think it should be better to link the test executable with the same
> object files generated during normal build for production code.

Which is often the case where the build environment is the same platform 
as the target.  If your policy is to disable assertions in production, 
then the waters become more muddy.

> One suggestion I read is to create a static library with all object
> files. The production executable and test executable are created linking
> this static library.

Common practice, however there are likely to be more than one library, 
or the libraries my be dynamic.

> This approach can be used to break and replace dependecies of a module
> under test. Indeed, if you specify the test doubles (replacing modules)
> before static library to the linker, it will use the test doubles
> instead of real modules.
> 
> Is it your preferred method? Are there other better ways?

Using dynamic libraries allows for function interposition which makes 
mocking easier.

-- 
Ian.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.c

csiph-web