elementary-dev-community team mailing list archive

[Craig <weberc2@xxxxxxxxx>]

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