elementary-dev-community team mailing list archive

[Craig <weberc2@xxxxxxxxx>]

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