elementary-dev-community team mailing list archive

[Goncalo Margalho <g@xxxxxxxxxxxxx>]

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