elementary-dev-community team mailing list archive

[Craig <weberc2@xxxxxxxxx>]

Nor am I. But I think the first step would be to explore what can be done
with the existing tools (assuming there are any that are still supported).
I find that I rarely need much more than a simple facility with the ability
to create test cases and do setup/teardown so if we can find anything that
provides even that, I think we can go a long way.


On Thu, Apr 4, 2013 at 10:45 AM, Goncalo Margalho <g@xxxxxxxxxxxxx> wrote:

> I would be interested but I'm not the best vala developer for sure.
>
>
> On Thu, Apr 4, 2013 at 4:40 PM, Craig <weberc2@xxxxxxxxx> wrote:
>
>> If we can get a number of experienced test practitioners and Vala
>> developers to commit to it, I wouldn't mind contributing to a test
>> framework development. Would anyone else be interested?
>>
>>
>> On Thu, Apr 4, 2013 at 10:13 AM, Craig <weberc2@xxxxxxxxx> wrote:
>>
>>> *Would it be feasible to create a Unit Test team on launchpad with the
>>> sole purpose of specializing in adding testing to projects and writing the
>>> tests required to kill regression bugs before they kill us? - Dane*
>>> *
>>> *
>>> If we do this, I would expect it to be short term only. Developers
>>> should be responsible for testing their own code and "Test Engineers"
>>> should be primarily responsible for giving the devs the tools/training they
>>> need to test their own work. I propose instead that we only implement tests
>>> when we do bug fixes. If a bug crops up, we analyze what caused it and then
>>> we write a test to prevent any such bug from appearing (not just that
>>> specific bug, but any bug in that class of bugs).
>>>
>>> For example, I recently worked on a system that takes a config file,
>>> parses its key/value pairs into a map, and then exposes its values in the
>>> form of methods called "string GetValueOfKey1()", "string
>>> GetValueOfKey2()", etc. These functions simply contained "return
>>> map.GetValue("key1");". This worked fine as long as the configuration file
>>> was setup correctly; however, as soon as someone made a mistake in the
>>> config file (accidentally renamed "key1" to "Key1" or some such) the
>>> application crashed because GetValueOfKey1() couldn't find "key1" in the
>>> map structure. This error *ultimately resulted from* unhandled input, I
>>> created a test to test for *all kinds* of bad input and then
>>> implemented the input handling.
>>>
>>> Applying tests where they're useful prevents us from testing stable
>>> code. And then moving forward, we can write tests for all new functionality.
>>>
>>>
>>> On Thu, Apr 4, 2013 at 10:00 AM, Craig <weberc2@xxxxxxxxx> wrote:
>>>
>>>> *If anyone is interested in starting a Vala Unit Test project under
>>>> the umbrella of the elementary community, I'm sure we could get quite a bit
>>>> of traction from the Vala community at large and I would love to help out.
>>>> - Dane Henson*
>>>> *
>>>> *
>>>> Not only that, but I imagine it would garner quite a lot of
>>>> professional developer attention for elementary, since professional devs
>>>> seem dramatically more exposed to (and interested in) formal testing than
>>>> hobbyist developers.
>>>>
>>>> *I apologize for spamming the mailing list. - Dane Henson*
>>>> Please don't apologize--from the sounds of it, there is quite a bit of
>>>> consensus that this is a subject that needs to be discussed. And I for one
>>>> have found each of your messages profitable.
>>>>
>>>> *Unit testing is boring to write so if we just said "Everybody. Write
>>>> unit tests. All Projects. Now." it would really take on. On companies and
>>>> when developers are paid to work, they can write and put tests everywhere,
>>>> but it's harder for us. - David Gomes*
>>>> *
>>>> *
>>>> David, I used to think that as well; however, once you learn to write
>>>> tests correctly (I'm starting that process myself) it becomes more
>>>> exciting. As Dane mentions later in the thread, when you build the bucket
>>>> around the water (write tests for existing code), it is certainly drudgery;
>>>> however, when you write tests *before* you implement the
>>>> functionality, you
>>>>
>>>>    1. wind up with better code (because code must be written in neat
>>>>    modules to provide your tests access to the inputs/outputs they need)
>>>>    2. get the excitement of writing code and watching your tests
>>>>    pass/fail (and as you learn to write better tests, you get detailed
>>>>    information about exactly what caused the failure)
>>>>    3. can change your code fearlessly, knowing that if anything
>>>>    breaks, you will be notified immediately
>>>>
>>>> The whole process becomes at least a little more exciting, especially
>>>> if you've experienced a huge untested code base and the fear that comes
>>>> with having to make a change or implement a feature lest the whole thing
>>>> come tumbling down on you.
>>>>
>>>> *While if we (developers) use the first approach, which is called TDD
>>>> is much better. We write the test first so we define how our app should
>>>> behave and how our code is structured already (so all the thinking of the
>>>> code structure you do it in the tests)  which is really great. - Goncalo
>>>> *
>>>> *
>>>> *
>>>> TDD = Test Driven Development (for the uninitiated). I elaborated on
>>>> this process to some extent in my previous paragraph.
>>>>
>>>> We can also do BDD , if there's no framework for this we can probably
>>>> create something, for more infos you can check cucumber for Ruby. *Bdd
>>>> let's you write the tests in PLAIN english, so who does the mockups could
>>>> write the tests as well. that would be great. - Goncalo*
>>>> *
>>>> *
>>>> BDD = Behavior Driven Development. It's either the same thing or very
>>>> closely related to ATDD (Acceptance Test Driven Development). In either
>>>> case, the general idea is that you specify what the entire system *must
>>>> do* (system requirements/acceptance criteria) and then you write tests
>>>> to verify each requirement. This sort of test might look like:
>>>>
>>>> "WHEN the bold button is pressed
>>>>  AND the string 'abcd' is typed,
>>>>  EXPECT the text view to contain the string 'abcd' in bold"
>>>>
>>>> Then, for each line, you write a function that implements either the
>>>> setup (the WHEN/AND portion) or the evaluation (the EXPECT portion) and
>>>> then the framework puts the pieces together and executes the test. The code
>>>> for the test (in pseudocode) might look like this:
>>>> func pressBoldButton () {
>>>>    theApp.boldButton.setPressed (true)
>>>> }
>>>> func type(string input) {
>>>>    theApp.InsertAtCursor (input)
>>>> }
>>>> func verifyContents () {
>>>>    start := 0
>>>>    end := 3
>>>>    contents := theApp.GetFormattedSubStr (start, end)
>>>>    contentsAreBold := contents.isBold()
>>>>    letters := contents.getPlainTextString()
>>>>
>>>>    Testing.Expect (contentsAreBold);
>>>>    Testing.Expect (letters == "abcd")
>>>> }
>>>>
>>>> On Thu, Apr 4, 2013 at 9:11 AM, Dane Henson <dane@xxxxxxxxxxxxxxxx>wrote:
>>>>
>>>>> Here is another practical post I found interesting regarding setting
>>>>> up Unit Tests in Vala with Cmake:
>>>>>
>>>>>
>>>>> http://blog.remysaissy.com/2012/11/setting-up-unit-tests-in-vala-project.html
>>>>>
>>>>> I apologize for spamming the mailing list.
>>>>>
>>>>>
>>>>> On Thu, Apr 4, 2013 at 8:56 AM, Sergey "Shnatsel" Davidoff <
>>>>> sergey@xxxxxxxxxxxxxxxx> wrote:
>>>>>
>>>>>> I strongly recommend anyone interested in automated testing to read
>>>>>> through Martin Pitt's Ubuntu Dev Week session on the topic. He's the one
>>>>>> responsible for most of unit testing in Ubuntu (he's also the author of
>>>>>> Apport which we already use). His IRC nick is "pitti" and the session logs
>>>>>> can be found at
>>>>>> http://irclogs.ubuntu.com/2013/01/31/%23ubuntu-classroom.html
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Sergey "Shnatsel" Davidoff
>>>>>> OS architect @ elementary
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Mailing list: https://launchpad.net/~elementary-dev-community
>>>>> Post to     : elementary-dev-community@xxxxxxxxxxxxxxxxxxx
>>>>> Unsubscribe : https://launchpad.net/~elementary-dev-community
>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>
>>>>>
>>>>
>>>
>>
>> --
>> Mailing list: https://launchpad.net/~elementary-dev-community
>> Post to     : elementary-dev-community@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~elementary-dev-community
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>