elementary-dev-community team mailing list archive

[Craig <weberc2@xxxxxxxxx>]

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