Re: [Elementary-dev-community] Granite's IconFactory
You should take a look at the code. I don't remember how it is used. — Sent from Mailbox for iPhone On Wed, Apr 3, 2013 at 10:56 PM, David Gomes da...@elementaryos.org wrote: Do you know how hard it would be to make Files stop using IconFactory.vala? On Mon, Apr 1, 2013 at 7:45 PM, Mario Guerriero mefri...@gmail.com wrote: Files is using it. — Sent from Mailbox https://bit.ly/SZvoJe for iPhone On Mon, Apr 1, 2013 at 8:25 PM, Chris Timberlake gam...@gmail.com wrote: Is there a way to add compile time warnings to it? In the event developers are using it and are unknowing? I'm not knowledgeable about adding compile time warnings in Vala but it might be worth it. On Apr 1, 2013 11:23 AM, Sergey Shnatsel Davidoff ser...@elementaryos.org wrote: I suggest deprecating it instead of removing it right away. 2013/4/1 David Gomes da...@elementaryos.org I can only remove it when Noise stops using it. On Mon, Apr 1, 2013 at 7:21 PM, Victor victoredua...@gmail.com wrote: I'm sure Mario has used it in many of his projects. In my humble opinion, that class it not a big deal. It's only a wrapper/facade around one method from GTK+. Would you mind removing the StatusBar class too? It is hacky, ugly and incomplete and only Noise is using it. On Mon, Apr 1, 2013 at 12:06 PM, David Gomes da...@elementaryos.org wrote: Hello there, There's a class/object/file in Granite called IconFactory.vala, you can check it out here - http://bazaar.launchpad.net/~elementary-pantheon/granite/granite/view/head:/lib/Services/IconFactory.vala . Is anybody using it and definitely dependent on it? We're considering removing it and I need to know if it's necessary. Best regards, David Munchor Gomes -- 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 -- 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
[Elementary-dev-community] Testing
Hello everyone, I'm curious what you devs do for testing? I'm not particularly familiar with Vala, but I'm learning a lot about testing at work and I'm trying to develop myself to that end in my free time. I'm sending this email because I'd like to get a pulse on what you Elementary devs think about testing and what you actually do to test your code. Also, please feel encouraged to talk about what you've done in the past, what has/hasn't worked for you, and generally what your philosophy is about testing (or whether you have no philosophy). Individual comments and comments on behalf of elementary as a whole are both welcome. Sound off! Thanks, Craig -- 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
Re: [Elementary-dev-community] Testing
Individual comment from a non-dev who has just observed devs: it would seem we have no formal testing policy but that we gravely need one. Code is developed and requested to be merged by dev A, then dev B looks the code itself over. Hopefully at this point dev B would then build it and test the crap out of it to make sure everything still works perfectly, but I feel that doesn't get done thoroughly as often as it should and consequently regressions slip through. Automated and standardized testing would be boss. Regards, Cassidy James On Apr 4, 2013 7:52 AM, Craig webe...@gmail.com wrote: Hello everyone, I'm curious what you devs do for testing? I'm not particularly familiar with Vala, but I'm learning a lot about testing at work and I'm trying to develop myself to that end in my free time. I'm sending this email because I'd like to get a pulse on what you Elementary devs think about testing and what you actually do to test your code. Also, please feel encouraged to talk about what you've done in the past, what has/hasn't worked for you, and generally what your philosophy is about testing (or whether you have no philosophy). Individual comments and comments on behalf of elementary as a whole are both welcome. Sound off! Thanks, Craig -- 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
Re: [Elementary-dev-community] Testing
Yes, testing is sorely needed. I started down the path of finding the best solution for Vala Unit Testing, but couldn't find any great options. Currently, all projects that pursued the xUnit (https://en.wikipedia.org/wiki/XUnit) model for Vala have fallen out of development and only their shells remain. I reached out to the Yorba devs, who appear to hold a repository for the old 'valadate' project but they are in the same position we are in. I believe they have done some testing with the built-in GObject unit test suite ( https://live.gnome.org/Vala/TestSample), but it has been found to be severely lacking by anyone who knows anything about unit testing. As with most OSS developers, I started to scratch that itch and realized that it is a little bit beyond my skill set. The code I started to write remains unusable, rotting away somewhere on one of my hdd platters in a folder called 'vunit'. 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. On Thu, Apr 4, 2013 at 7:59 AM, Sergey Shnatsel Davidoff ser...@elementaryos.org wrote: This is what I've developed for testing: https://lists.launchpad.net/elementary-dev-community/msg01948.html I've also created Glimpse - a system for sandboxed testing, but it lacks a D-bus proxy which is needed for adding/removing apps via GUI. See http://shnatsel.blogspot.com/2011/07/weve-just-revolutionized-alpha-testing.htmland http://shnatsel.blogspot.com/2012/05/state-of-glimpse.html I don't think we have any unit testing in place yet. Midori probably has but that's it. 2013/4/4 Craig webe...@gmail.com Hello everyone, I'm curious what you devs do for testing? I'm not particularly familiar with Vala, but I'm learning a lot about testing at work and I'm trying to develop myself to that end in my free time. I'm sending this email because I'd like to get a pulse on what you Elementary devs think about testing and what you actually do to test your code. Also, please feel encouraged to talk about what you've done in the past, what has/hasn't worked for you, and generally what your philosophy is about testing (or whether you have no philosophy). Individual comments and comments on behalf of elementary as a whole are both welcome. Sound off! Thanks, Craig -- 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 -- 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
Re: [Elementary-dev-community] Testing
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. For now what we just do is we test the interface, the new features and some old features too to see if they remain unaffected. On Thu, Apr 4, 2013 at 1:51 PM, Craig webe...@gmail.com wrote: Hello everyone, I'm curious what you devs do for testing? I'm not particularly familiar with Vala, but I'm learning a lot about testing at work and I'm trying to develop myself to that end in my free time. I'm sending this email because I'd like to get a pulse on what you Elementary devs think about testing and what you actually do to test your code. Also, please feel encouraged to talk about what you've done in the past, what has/hasn't worked for you, and generally what your philosophy is about testing (or whether you have no philosophy). Individual comments and comments on behalf of elementary as a whole are both welcome. Sound off! Thanks, Craig -- 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
Re: [Elementary-dev-community] Testing
Our m̶o̶s̶t̶ ̶e̶f̶f̶e̶c̶t̶i̶v̶e̶ only regression testing is in Files. It goes Cody, I think I fixed crash X and I add it to my list of crash report email titles I look for to reoccur. On Thu, Apr 4, 2013 at 8:25 AM, David Gomes da...@elementaryos.org wrote: 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. For now what we just do is we test the interface, the new features and some old features too to see if they remain unaffected. On Thu, Apr 4, 2013 at 1:51 PM, Craig webe...@gmail.com wrote: Hello everyone, I'm curious what you devs do for testing? I'm not particularly familiar with Vala, but I'm learning a lot about testing at work and I'm trying to develop myself to that end in my free time. I'm sending this email because I'd like to get a pulse on what you Elementary devs think about testing and what you actually do to test your code. Also, please feel encouraged to talk about what you've done in the past, what has/hasn't worked for you, and generally what your philosophy is about testing (or whether you have no philosophy). Individual comments and comments on behalf of elementary as a whole are both welcome. Sound off! Thanks, Craig -- 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 -- Cody Garver -- 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
Re: [Elementary-dev-community] Testing
We also had a regression on Granite the other day. It goes I fixed this bug and I tested that bug but then I didn't test crazy-weird behaviour and it turned out it broke some things. Of course, action has been taken to fix it, but it can't be merged yet. (sorry for sending this email to Cody twice, I meant to Reply To All. On Thu, Apr 4, 2013 at 2:31 PM, Cody Garver c...@elementaryos.org wrote: Our m̶o̶s̶t̶ ̶e̶f̶f̶e̶c̶t̶i̶v̶e̶ only regression testing is in Files. It goes Cody, I think I fixed crash X and I add it to my list of crash report email titles I look for to reoccur. On Thu, Apr 4, 2013 at 8:25 AM, David Gomes da...@elementaryos.orgwrote: 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. For now what we just do is we test the interface, the new features and some old features too to see if they remain unaffected. On Thu, Apr 4, 2013 at 1:51 PM, Craig webe...@gmail.com wrote: Hello everyone, I'm curious what you devs do for testing? I'm not particularly familiar with Vala, but I'm learning a lot about testing at work and I'm trying to develop myself to that end in my free time. I'm sending this email because I'd like to get a pulse on what you Elementary devs think about testing and what you actually do to test your code. Also, please feel encouraged to talk about what you've done in the past, what has/hasn't worked for you, and generally what your philosophy is about testing (or whether you have no philosophy). Individual comments and comments on behalf of elementary as a whole are both welcome. Sound off! Thanks, Craig -- 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 -- Cody Garver -- 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
Re: [Elementary-dev-community] Testing
David, I understand where you're coming from and I have worried about that in the past. There are two approaches for Unit Testing. The strong approach is to figure out what you want the app to do (i.e. design the framework), describe that app's functions and libraries using tests, then write your code around it. If at some point the requirements change, you can modify the Unit Tests. It's boring, but provides a very stable foundation for apps. The second approach (and what we would have to do for all existing projects) is to write the tests around the app. This approach is like trying to build a bucket around the water, but it can be done and any development going forward is more likely to not break the core functionality of the app. 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? Also, Adam (at Yorba) and I came up with the conclusion that rolling a new Unit Test framework might be the best option. Here's a quote from Adam at Yorba: You might also want to consider rolling your own simple unit testing framework in Vala without even using Glib.Test - sometimes I think that might be the easiest path forward here. So, this could be a really big project, but I see a lot of merit to it. On Thu, Apr 4, 2013 at 8:25 AM, David Gomes da...@elementaryos.org wrote: 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. For now what we just do is we test the interface, the new features and some old features too to see if they remain unaffected. On Thu, Apr 4, 2013 at 1:51 PM, Craig webe...@gmail.com wrote: Hello everyone, I'm curious what you devs do for testing? I'm not particularly familiar with Vala, but I'm learning a lot about testing at work and I'm trying to develop myself to that end in my free time. I'm sending this email because I'd like to get a pulse on what you Elementary devs think about testing and what you actually do to test your code. Also, please feel encouraged to talk about what you've done in the past, what has/hasn't worked for you, and generally what your philosophy is about testing (or whether you have no philosophy). Individual comments and comments on behalf of elementary as a whole are both welcome. Sound off! Thanks, Craig -- 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
Re: [Elementary-dev-community] Testing
2013/4/4 Craig webe...@gmail.com Sergey, that looks very interesting, although I'm a little confused--what are the differences between your first link and Glimpse? My first link is my scripts for easily testing code proposed for merging. I created them to offload the burden of testing proposed code from developers to adventurous users. However, nobody understand what are those scripts and why they're needed unless I explain it personally on IRC .I guess I suck at emailing people, but I always knew that... -- 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
Re: [Elementary-dev-community] Testing
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
Re: [Elementary-dev-community] Testing
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
Re: [Elementary-dev-community] Testing
We do unit and behavorial testing at where i work, and i think it's great. Writing tests before you develop the actual feature really makes you think why your feature should do what and when it should do so. Maybe we could build vala tests for granite. That would mean we would have to write tests for existing features too, but when that is done, we can implement features with first creating a test (a spec) for it, and then actually implementing it according to the spec. We could then integrate some kind of continuous integration using something like Travis (if it does vala), or if launchpad offers that functionality, we can use that. If it works for granite, we could slowly and steadily move to testing in all elementary projects. I think this would in the long term greatly improve stability of the system and individual apps, will encourage good and maintainable code and architecture of apps, and it would make elementary developing more professional. Just my 2 cents... Jaap Op 4 apr. 2013 16:11 schreef Dane Henson d...@elementaryos.org het volgende: 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
Re: [Elementary-dev-community] Testing
*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
Re: [Elementary-dev-community] Testing
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 @
Re: [Elementary-dev-community] Testing
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 webe...@gmail.com 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 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
Re: [Elementary-dev-community] Testing
I would be interested but I'm not the best vala developer for sure. On Thu, Apr 4, 2013 at 4:40 PM, Craig webe...@gmail.com 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 webe...@gmail.com 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 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
Re: [Elementary-dev-community] Testing
I'm not so sure we need a solution bound to Vala specifically, because: 1. We have automated UI testing covered by Ubuntu's regression testing framework 2. We have D-bus testing coverted by Ubuntu's regression testing framework 3. Vala translates to C so we can use a C unit testing system for functions For details on what Ubuntu do see Martin Pitt's UDW session, 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
Re: [Elementary-dev-community] Testing
Sergey, how do you write code in Vala and write tests in C? it becomes too difficult for a developer, don't you think? On Thu, Apr 4, 2013 at 5:18 PM, Sergey Shnatsel Davidoff ser...@elementaryos.org wrote: I'm not so sure we need a solution bound to Vala specifically, because: 1. We have automated UI testing covered by Ubuntu's regression testing framework 2. We have D-bus testing coverted by Ubuntu's regression testing framework 3. Vala translates to C so we can use a C unit testing system for functions For details on what Ubuntu do see Martin Pitt's UDW session, 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
Re: [Elementary-dev-community] Testing
+1 Sergey, that page is massive. Could you send us the interesting parts? On Thu, Apr 4, 2013 at 11:59 AM, Goncalo Margalho g...@margalho.info wrote: Sergey, how do you write code in Vala and write tests in C? it becomes too difficult for a developer, don't you think? On Thu, Apr 4, 2013 at 5:18 PM, Sergey Shnatsel Davidoff ser...@elementaryos.org wrote: I'm not so sure we need a solution bound to Vala specifically, because: 1. We have automated UI testing covered by Ubuntu's regression testing framework 2. We have D-bus testing coverted by Ubuntu's regression testing framework 3. Vala translates to C so we can use a C unit testing system for functions For details on what Ubuntu do see Martin Pitt's UDW session, 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
Re: [Elementary-dev-community] Testing
Nor am I. But I think the first step would be to explore what can be done with the existing tools (assuming there are any that are still supported). I find that I rarely need much more than a simple facility with the ability to create test cases and do setup/teardown so if we can find anything that provides even that, I think we can go a long way. On Thu, Apr 4, 2013 at 10:45 AM, Goncalo Margalho g...@margalho.info wrote: I would be interested but I'm not the best vala developer for sure. On Thu, Apr 4, 2013 at 4:40 PM, Craig webe...@gmail.com 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 webe...@gmail.com 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 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