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 1 of 2  [1] 2  Next page →

#138153 — Unit test in C and breaking dependencies

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?

[toc] | [next] | [standalone]

#138156

On 11/20/18 08: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.
> 
> 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?

I consider it an absolute necessity to test the program as it is
actually compiled and linked for delivery. However, unless the testing
routines are part of the program, there's things you want to test that
you can't test using the actual delivered program. (And if the testing
routines are part of the delivered program, they themselves need to be
tested, which leads to infinite regression).

I allow test programs which link an object to different things than the
object will be linked to for the delivered program: instrumented
versions of subroutines (which might or might not otherwise be dummy
routines), and a test driver that is different from the routine that
normally calls the one being tested. The key point is that these tests
are in addition to the ones performed on the actual delivered program;
they do not replace those tests, they supplement them.

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

#138170

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.

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

#138172

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.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

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

#138173

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. Even not using libraries is something
hard to maintain because we need to create makefiles for each 
unit test. (In my case I need to create visual studio projects)

The proposal for a modular build system for C also would help 
this kind of unit test creation because makefiles would not be
not necessary.
Let's say I have a file4.c I can create a file4_test.c.
To compile this unit test
cc auto file4_test.c

To cover all files of the project you can imagine how many
makefiles we would have. 

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

#138182

On Wed, 2018-11-21, 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."

Ah, ok.  That wasn't obvious, but that might be because the original
posting confused me.

> 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. 

Sure.

> Having a library just for file1, file2 .. would 
> be hard do maintain. Even not using libraries is something
> hard to maintain because we need to create makefiles for each 
> unit test. (In my case I need to create visual studio projects)

Maybe that's a Visual Studio limitation: I've never used it. For
makefiles, as I wrote, creating static libraries as an intermediate
step makes them even easier to write, because you don't have to repeat
yourself or use those nasty variables.

> The proposal for a modular build system for C also would help 
> this kind of unit test creation because makefiles would not be
> not necessary.
> Let's say I have a file4.c I can create a file4_test.c.
> To compile this unit test
> cc auto file4_test.c
>
> To cover all files of the project you can imagine how many
> makefiles we would have. 

Let me describe how I structure a standalone project 'proj' which
contains two binaries 'foo' and 'bar', and unit tests.  I'll use Make
syntax for the dependencies: read "a: b" as "a has an immediate
dependency on b" or "a is built from b".

    foo: foo.o libproj.a
    bar: bar.o libproj.a
    test: test_driver.o libtest.a libproj.a

    test_driver.c: libtest.a

    libproj.a: a.o b.o c.o d.o   # normal source code
    libtest.a: test/a.o test/d.o # unit tests, and maybe helper code

The unit tests all end up in a single executable, so they are easy to
run.  test_driver.c would be generated by your unit test tools (I
don't know what people typically use for that).

No need for multiple makefiles, and not a lot of overhead in general
for having unit tests.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

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

#138194

On Wednesday, November 21, 2018 at 6:50:53 PM UTC-2, Jorgen Grahn wrote:
[...]
> Let me describe how I structure a standalone project 'proj' which
> contains two binaries 'foo' and 'bar', and unit tests.  I'll use Make
> syntax for the dependencies: read "a: b" as "a has an immediate
> dependency on b" or "a is built from b".
> 
>     foo: foo.o libproj.a
>     bar: bar.o libproj.a
>     test: test_driver.o libtest.a libproj.a
> 
>     test_driver.c: libtest.a
> 
>     libproj.a: a.o b.o c.o d.o   # normal source code
>     libtest.a: test/a.o test/d.o # unit tests, and maybe helper code
> 
> The unit tests all end up in a single executable, so they are easy to
> run.  test_driver.c would be generated by your unit test tools (I
> don't know what people typically use for that).
> 
> No need for multiple makefiles, and not a lot of overhead in general
> for having unit tests.

I am not sure if I understood. 
Are you testing two libraries at once?

>foo: foo.o libproj.a
>     bar: bar.o libproj.a
>     test: test_driver.o libtest.a libproj.a

Is test lib or executable? Does it test
the public interface of foo and bar?

Source code also has a public interfaces and 
private interfaces.
Some libraries can have many parts and the public 
interface let's say your lib.h has only few functions.

What I did last time was just create all_tests.c in inside 
the project I want to test and compile together.

/*all_tests.h*/
#if TEST
void AllTests();
#endif

/*all_tests.c*/
/*lot of includes*/
#if TEST
static void Test1(){...}
static void TestN(){...}
void AllTests()
{
  Test1();
  ...
  TestN();
}
#endif

The problem with this approach is that I don't have
modularity to move tests.

Then what I am planning to do is to have the same degree
of modularity for the module and its unit test.

Generally a project is like a triangle of dependencies.

*
**
***
******

At the top, we have a single file with main() that 
depends on others.
At the bottom we have the files that doesn't depend
on anything else (from this project).
And at the middle we have the files that depends on the level
below or at the same level. (Ideally I try to do that)

I am planning to test each file with a executable.
Let's say file1 is at bottom then I have
file1.c file1.h file1_test.c that generates file1_test.exe
I will keep file1_test.c in a separated directory (\Tests).

Then In case I need to move file1.h and file1.c for another 
project I can just copy file1_test.c and move it as well.
(The way I was doing before I was bad to to that.)

At the middle I have let's say file5.c that depends on file1.c 
and others. I will have file5_test.c and file5_test.exe. 
This file5_test is not testing again the file1.c. 
It assumes file1.c is perfect and tests file5.c functions only.

At the end I will have several test executes and I will create 
a batch file to call everything.

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

#138195

Thiago Adams:

>Generally a project is like a triangle of dependencies.
>
>                          *
>                          **
>                          ***
>                          ******
>
>At the top, we have a single file with main() that depends
>on others.  At the bottom we have the files that doesn't
>depend on anything else (from this project).  And at the
>middle we have the files that depends on the level below or
>at the same level. (Ideally I try to do that)

This is a special kind of layered dependency hierarchy that
is very hard to observe strictly.  No two modules from any
different layers except the top one may use the same third
module from a lower level.  This is violated, for example,if
you have a low-level string manipulation routines used by
different modules through out the hierarchy.

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

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

#138197

On Thursday, November 22, 2018 at 10:30:58 AM UTC-2, Anton Shepelev wrote:
> Thiago Adams:
> 
> >Generally a project is like a triangle of dependencies.
> >
> >                          *
> >                          **
> >                          ***
> >                          ******
> >
> >At the top, we have a single file with main() that depends
> >on others.  At the bottom we have the files that doesn't
> >depend on anything else (from this project).  And at the
> >middle we have the files that depends on the level below or
> >at the same level. (Ideally I try to do that)
> 
> This is a special kind of layered dependency hierarchy that
> is very hard to observe strictly.  No two modules from any
> different layers except the top one may use the same third
> module from a lower level.  This is violated, for example,if
> you have a low-level string manipulation routines used by
> different modules through out the hierarchy.

In my C parser project I have the scanner that also
is a preprocessed scanner. To do the preprocessor
we need evaluate #if. To evaluate we need an expression
parses.
The conclusion... my scanner(tokenizer)is depending on the 
parser. The bottom part is depending on the top part that also
depends on the bottom part. 
It's hard to reuse this preprocessor scanner in other project.

Mocking also can help in some cases.

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

#138196

On Thursday, November 22, 2018 at 10:10:28 AM UTC-2, Thiago Adams wrote:
[...]
> Then what I am planning to do is to have the same degree
> of modularity for the module and its unit test.
> 
> Generally a project is like a triangle of dependencies.
> 
> *
> **
> ***
> ******
> 
> At the top, we have a single file with main() that 
> depends on others.
> At the bottom we have the files that doesn't depend
> on anything else (from this project).
> And at the middle we have the files that depends on the level
> below or at the same level. (Ideally I try to do that)
> 
> I am planning to test each file with a executable.
> Let's say file1 is at bottom then I have
> file1.c file1.h file1_test.c that generates file1_test.exe
> I will keep file1_test.c in a separated directory (\Tests).
> 
> Then In case I need to move file1.h and file1.c for another 
> project I can just copy file1_test.c and move it as well.
> (The way I was doing before I was bad to to that.)
> 
> At the middle I have let's say file5.c that depends on file1.c 
> and others. I will have file5_test.c and file5_test.exe. 
> This file5_test is not testing again the file1.c. 
> It assumes file1.c is perfect and tests file5.c functions only.
> 
> At the end I will have several test executes and I will create 
> a batch file to call everything.


I don't think this approach is the easiest. I will
have to configure many executables. That means using
VC++ is to create a solution test.sln and many 
test1.proj to generate each exe.
To create each project I will have to check the dependencies
(add into the project the files necessary)

But the advantage is that I know that this approach can scale 
very well. I can start a big project with 1 test case
and then increase as the project grows and the next module
is relying on tested-covered parts. 

Each test case will also be a documentation how to use
some data and also documentation of dependencies. So
the test case is also a way to learn and understand
the data types and its algorithms.

For instance, I can have more than one project for parsing. 
Let's say XML and JSON parser. Both projects depends on 
InputStream. InputStream has its own test case that shows
what files are necessary and how to use it.
To reuse InputStream in both projects I will have to move
all files necessary and all unit tests that InputStream
depends. Also is interesting to keep the same directory 
organization in both projects.

The directory organization I am planning is:

All c and h files mixed.

[Project]
|
|.. file1.c 
|.. file1.h
|
|.. fileN.c 
|.. fileN.h
|
|..[Test]
...| file1_test.c
...| module_test.c


Note that inside Test directory I can have
file1_test that is a test for a "bottom" file
and I also have module_test. The idea of module
is some functionality that I can reuse in other 
project. This module depends on the files that
are mixed. The files are mixed because the same
file can be used in more than one module.
The test cases also help to understand this structure.


 
 

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

#138198

On Thu, 2018-11-22, Thiago Adams wrote:
> On Wednesday, November 21, 2018 at 6:50:53 PM UTC-2, Jorgen Grahn wrote:
> [...]
>> Let me describe how I structure a standalone project 'proj' which
>> contains two binaries 'foo' and 'bar', and unit tests.  I'll use Make
>> syntax for the dependencies: read "a: b" as "a has an immediate
>> dependency on b" or "a is built from b".
>> 
>>     foo: foo.o libproj.a
>>     bar: bar.o libproj.a
>>     test: test_driver.o libtest.a libproj.a
>> 
>>     test_driver.c: libtest.a
>> 
>>     libproj.a: a.o b.o c.o d.o   # normal source code
>>     libtest.a: test/a.o test/d.o # unit tests, and maybe helper code
>> 
>> The unit tests all end up in a single executable, so they are easy to
>> run.  test_driver.c would be generated by your unit test tools (I
>> don't know what people typically use for that).
>> 
>> No need for multiple makefiles, and not a lot of overhead in general
>> for having unit tests.
>
> I am not sure if I understood. 
> Are you testing two libraries at once?

I'm not testing libraries: I'm testing (part of) the code in the
project 'proj'.

>>foo: foo.o libproj.a
>>     bar: bar.o libproj.a
>>     test: test_driver.o libtest.a libproj.a

That should have read:

foo: foo.o libproj.a
bar: bar.o libproj.a
test: test_driver.o libtest.a libproj.a

> Is test lib or executable?

I assumed knowledge of Unix file naming: foo.o (object file), libfoo.a
(static library, aka archive), foo (executable, in this context).

> Does it test the public interface of foo and bar?

See above: it tests the code in the project 'proj'.

> Source code also has a public interfaces and 
> private interfaces.
> Some libraries can have many parts and the public 
> interface let's say your lib.h has only few functions.

I think the misunderstanding is here.  I'm talking about static
libraries in the sense "a collection of object files", and I believe
the OP was too.

There's this other meaning: library in the sense "an implementation of
certain functionality, with a well-known API, exposed through header
files".  There was no such library in my example.

[snip]

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

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

#138200

On Thursday, November 22, 2018 at 3:08:28 PM UTC-2, Jorgen Grahn wrote:
[...]
> I think the misunderstanding is here.  I'm talking about static
> libraries in the sense "a collection of object files", and I believe
> the OP was too.

Yes, I was thinking in reusable modules, tested separately.

I still don't know how do you compile. Do you use command line
(like batch files) or makefiles?

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

#138211

On Fri, 2018-11-23, Thiago Adams wrote:
> On Thursday, November 22, 2018 at 3:08:28 PM UTC-2, Jorgen Grahn wrote:
> [...]
>> I think the misunderstanding is here.  I'm talking about static
>> libraries in the sense "a collection of object files", and I believe
>> the OP was too.
>
> Yes, I was thinking in reusable modules, tested separately.
>
> I still don't know how do you compile. Do you use command line
> (like batch files) or makefiles?

When I get to choose, I use makefiles.  My "proj" example upthread was
realistic (but not a complete Makefile, since I was just showing how
executables, unit tests and intermediate libraries fit together
through Make dependencies).

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

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

#138216

Maybe I'm missing something, but what happens if the machine that you're writing and testing a piece of had uses a different version of the library than the target machine? In that case, you would need two different programs.

And this is totally realistic because I've written code for a production machine that uses code written that was written 14 years earlier.

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

#138217

On Sat, 2018-11-24, Chad wrote:
> Maybe I'm missing something, but what happens if the machine that
> you're writing and testing a piece of had uses a different version
> of the library than the target machine? In that case, you would need
> two different programs.

You have to explain better what you're getting at.  You're responding
to a posting I wrote, although you didn't quote any of it.  But I only
described the mechanism I use for building a piece of software and its
unit tests.

It's true that I didn't bring cross-compilation into the picture.

> And this is totally realistic because I've written code for a
> production machine that uses code written that was written 14 years
> earlier.

I cannot decipher that sentence.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

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

#138260

On Saturday, November 24, 2018 at 4:50:14 AM UTC-8, Jorgen Grahn wrote:
> On Sat, 2018-11-24, Chad wrote:
> > Maybe I'm missing something, but what happens if the machine that
> > you're writing and testing a piece of had uses a different version
> > of the library than the target machine? In that case, you would need
> > two different programs.
> 
> You have to explain better what you're getting at.  You're responding
> to a posting I wrote, although you didn't quote any of it.  But I only
> described the mechanism I use for building a piece of software and its
> unit tests.
> 
> It's true that I didn't bring cross-compilation into the picture.

Yeah, I meant to say cross-compilation.

> 
> > And this is totally realistic because I've written code for a
> > production machine that uses code written that was written 14 years
> > earlier.
> 
> I cannot decipher that sentence.
> 

I *think* this is going outside the scope of Standard C, but when I write code for an embedded device that connects to a remote server, I need a test and production piece of software. This is because I need to add additional code to make the debugger work with the 1998 machine. But when I run the actual code, this debugging code needs to be stripped before the machine will electronically sign my code to ensure that it was me who wrote the code. 

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

#138303

On Mon, 2018-11-26, Chad wrote:
> On Saturday, November 24, 2018 at 4:50:14 AM UTC-8, Jorgen Grahn wrote:
>> On Sat, 2018-11-24, Chad wrote:
>> > Maybe I'm missing something, but what happens if the machine that
>> > you're writing and testing a piece of had uses a different version
>> > of the library than the target machine? In that case, you would need
>> > two different programs.
>> 
>> You have to explain better what you're getting at.  You're responding
>> to a posting I wrote, although you didn't quote any of it.  But I only
>> described the mechanism I use for building a piece of software and its
>> unit tests.
>> 
>> It's true that I didn't bring cross-compilation into the picture.
>
> Yeah, I meant to say cross-compilation.

>> > And this is totally realistic because I've written code for a
>> > production machine that uses code written that was written 14 years
>> > earlier.
>> 
>> I cannot decipher that sentence.
>> 
>
> I *think* this is going outside the scope of Standard C,

That's ok; the whole subthread was offtopic already.

> but when I write code for an embedded device that connects to a
> remote server, I need a test and production piece of software. This
> is because I need to add additional code to make the debugger work
> with the 1998 machine. But when I run the actual code, this
> debugging code needs to be stripped before the machine will
> electronically sign my code to ensure that it was me who wrote the
> code.

I still don't understand completely, but there are so many variations
on the theme "cross-compilation".  I count myself lucky when I can avoid
them by building and testing in the target environment!

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

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

#138333

On 28/11/2018 03:32, Jorgen Grahn wrote:
> On Mon, 2018-11-26, Chad wrote:
> 
>> but when I write code for an embedded device that connects to a
>> remote server, I need a test and production piece of software. This
>> is because I need to add additional code to make the debugger work
>> with the 1998 machine. But when I run the actual code, this
>> debugging code needs to be stripped before the machine will
>> electronically sign my code to ensure that it was me who wrote the
>> code.
> 
> I still don't understand completely, but there are so many variations
> on the theme "cross-compilation".  I count myself lucky when I can avoid
> them by building and testing in the target environment!

Assuming the build and target environments are one and the same!

You shouldn't even be running unit tests on the target environment, the 
are for testing the logic of your code.

-- 
Ian.

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

#138403

On Thursday, November 22, 2018 at 10:10:28 AM UTC-2, Thiago Adams wrote:
[...]
> What I did last time was just create all_tests.c in inside 
> the project I want to test and compile together.
[...]
> The problem with this approach is that I don't have
> modularity to move tests.
> 
> Then what I am planning to do is to have the same degree
> of modularity for the module and its unit test.
> 
[...]
> I am planning to test each file with a executable.
[...]
> At the end I will have several test executes and I will create 
> a batch file to call everything.


After some experience with the new approach, I think
the better way is to keep all together at the same
main VC++ solution.

Why?
The problem is that if you are constantly updating
your code than it is important to have everything 
at the same solution because you can easily guarantee
that you test still compiling when you make changes.

Also the rename tool (refactoring) will change the code
at your program and at your unit test. Having it separately
the refactoring tool will work just at your main project
then you need manually fix your unit test.

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

#138199

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.

> (In my case I need to create visual studio projects)

Well, yeah, sure. Visual Studio isn't very good at that, indeed.

> The proposal for a modular build system for C also would help 
> this kind of unit test creation because makefiles would not be
> not necessary.
> Let's say I have a file4.c I can create a file4_test.c.
> To compile this unit test
> cc auto file4_test.c
> 
> To cover all files of the project you can imagine how many
> makefiles we would have. 

Just one...

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web