brewtarget-devs team mailing list archive
Mailing list archive
Re: Unit tests
Awesome! Looking forward to what you dig up.
On Mon, May 12, 2014 at 12:38 PM, mik firestone <mikfire@xxxxxxxxx> wrote:
> Oddly enough, I have some experience with writing test code.
> Dumping all of the tests into the same class is going to not work well as
> soon as we get two or three classes tested. I suggest subclassing the Test
> class. So we would have Test::Recipe and Test::Equipment and so on. I think
> that should allow us to share the writing of the tests better and make it
> easier to add tests as we add more methods.
> I would suggest we make a test database. It doesn't ship, but saying "make
> test" will create it from a canned SQL script. We can populate it with
> everything we need. In fact, I think make test should delete the test db
> and recreate it every time, just to make sure we start from a known state.
> After that, we will just need to find a clever way to get Database::load()
> to open that one instead.
> I will read a bit more on how to do this in Qt, maybe dig a little a gcov
> or something and see if I come up with anything.
> On Mon, May 12, 2014 at 10:11 AM, Philip Lee <rocketman768@xxxxxxxxx>wrote:
>> I'm still thinking about how exactly to organize the tests and which ones
>> to write. I'd like suggestions after you guys look this over. Mostly, that
>> request was about structural changes that allow us to write the tests at
>> In any case, the overall idea is to write test cases for things we don't
>> want to break. Now, all the testing consists of me running brewtarget and
>> making sure it doesn't segfault or do crazy things, which is really pretty
>> poor. We need some better way to test the software. For example, we might
>> want to enter a test recipe and make sure it always calculates the same
>> parameters going forward to ensure we don't break anyone's recipes. Since
>> we'd like to do this sort of thing programatically (by running 'make test'
>> or whatever), there is Qt stuff to make classes for testing and handle all
>> of that.
>> For now, the test cases are contained in Testing.h/cpp. If you want to
>> add a test case, just add public slot with signature 'void f(void)', using
>> QVERIFY, QVERIFY2, QCOMPARE (qFuzzyCompare for floats) etc. to make all the
>> assertions. The test cases will be run with 'make test' and a summary will
>> print detailing the failed assertions.
>> One thing to try and maintain is the isolation of the test cases. I don't
>> want the test cases to modify any database already in ~/.config/brewtarget,
>> and I don't want it to be affected at all by that data or whatever current
>> settings you have. This means the test cases depend _only_ on the data and
>> code currently in the repository and the test results should be repeatable
>> and consistent across machines. I think I achieved this isolation with
>> Testing::initTestCase() (run before all test cases), but I could be wrong.
>> This is critical, and I'd like your help to make sure we are achieving it.
>> I am not at all set on the structure of the test classes/cases. I'm
>> hoping that when we start to write more test cases, it will become evident
>> how we should organize them, and I'm looking for your input on that.
>> On Mon, May 12, 2014 at 8:46 AM, mik firestone <mikfire@xxxxxxxxx> wrote:
>>> I just resync'd master with upstream and noticed we are preparing for
>>> the v2.1 release. Yay! I will work on updating the manual.
>>> I also noticed that the build included a brewtarget_tests.dir. I am
>>> assuming this is the result of the unit tests Phil added.
>>> Phil, can you give us a quick rundown on how to use and write the tests?
>>> In a world of ninja v. pirate, I pilot a Gundam
>>> Mailing list: https://launchpad.net/~brewtarget-devs
>>> Post to : brewtarget-devs@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~brewtarget-devs
>>> More help : https://help.launchpad.net/ListHelp
>> Philip G. Lee
> In a world of ninja v. pirate, I pilot a Gundam
Philip G. Lee