Craig, thanks to make everything more clear.
Unit test is not just having something to compare stuff but we need a great
mocking system. Does anyone have links for that as well?
On Thu, Apr 4, 2013 at 4:00 PM, Craig <webe...@gmail.com> 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 <d...@elementaryos.org> 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 <
>> ser...@elementaryos.org> 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@lists.launchpad.net
>> 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@lists.launchpad.net
> 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@lists.launchpad.net
Unsubscribe : https://launchpad.net/~elementary-dev-community
More help : https://help.launchpad.net/ListHelp
