After reading quite some threads here at StackOverflow, I have come to the conclusion that I should adopt to some form of test driven development/unit test (or at least explore the area).
And since we are talking about c code under Linux, I decided to give check a try (I don't know if this is the right choice but if it's no good I can always try something else later on).
But since this concept of unit test and unit test frameworks is totally new to me, I started out to do some unit test on a really small test code (but I was totally lost anyway and it felt like I was missing something).
This is what I have done so far, I created the following file:
(So the "normal program" is the main.c, my_pow.c and my_pow.h.)
This is my_pow.c
#include "my_pow.h" int my_pow(int a, int b) { return (a*b); }
Then I figured that in my_pow_test.c I put something like this:
#include <check.h> #include "my_pow.h" START_TEST (test_my_pow) { /* unit test code */ } END_TEST //do I need some sort off main here that calls test_my_pow?
This is basically the same as in the check manual chapter 3.1, but still not....
Could someone please push me in the right direction?
Thanks Johan
Update: No reason why I tried to use check I just thought I should start somewhere, maybe CUnit is a better choice (I think I would try that as well and then make a educated choice).
Update: Thanks @philippe for indirectly pointing out that the on-line documentation is only half of the truth, the example code that clarifies what the documentation talks about was already installed with the check package. In the Ubuntu case /usr/share/doc/check/example/tests/
Update: The code example was created so that you started out by looking at his first version, then the second one etc etc. So that you could follow how he creates a very basic test case/code from nothing up to something that is useful in a traditional TTD way.
And since my code was broken and I wanted the unit test to prove this, I cheated a little and tested against the real pow function. Something like this:
START_TEST (test_my_pow1) { int resultat = my_pow(3,3); int math = pow(3,3); fail_unless ( resultat == math, "Error on 3^3 != %d (%d)",math, resultat); }
However in the future I will not reproduce what is already in the stdlibs :-)
Related:
taken from searching [c] [unit-testing]
.
Unit testing is one of the most valuable types of automated testing. Getting started with it isn't the easiest thing, though. Many teams start wrong and then give up due to not reaping the benefits they were looking for.
A unit test typically comprises of three stages: plan, cases and scripting and the unit test itself. In the first step, the unit test is prepared and reviewed. The next step is for the test cases and scripts to be made, then the code is tested.
They told me to learn unit testing and write unit tests for a project that has 3000 lines and 35 classes approximately in 3 weeks. I did read Art of Unit Testing in 2 days and getting used to unit tests took another day already.
You created a first test case. Now you need to create a test suite (a group of test cases) and a runner.
I would recommend you try to compile their example first to validate your environment, although their documentation introduces new code via diff (source patch) which I do not find very convenient.
If ever you decide to try with another framework (minunit came to my mind immediately), I can point you to a "tutorial".
I'd be more inclined to go with CUnit which is part of the X-Unit series of test frameworks.
It's scalable to large suites of tests and has been in use for many years, hence mature.
Any reason why you didn't go with CUnit?
HTH
cheers,
Rob
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With