So say this code for example: http://bazaar.launchpad.net/~elementary-apps/pantheon-terminal/trunk/view/head:/src/TerminalWidget.vala#L37
Sometimes we have some issues with ReGex (see https://code.launchpad.net/~voldyman/pantheon-terminal/colon-fixed/+merge/180735 ). Is that the kind of thing we can use TDD for? Like have a bunch of URLs and see if Terminal detects them or not without any GUI, just terminal Found/Not Found messages? ~David "Munchor" Gomes On Mon, Aug 19, 2013 at 1:38 AM, Craig <webe...@gmail.com> wrote: > David, > > I understand and appreciate the difficulty; however, I've had exactly zero > questions about TDD. Like I said in the original post, I'm happy to answer > any questions you may have. > > Please take me up on that offer any time. > > Thanks, > Craig > On Aug 18, 2013 6:57 PM, "David Gomes" <da...@elementaryos.org> wrote: > >> This, this and this. >> >> And also many of the developers like me aren't really experienced with >> TDD and will have to take some time to study, learn and adapt to it. You >> can't just come here and tell developers, many of whom inexperienced young >> amateur programmers, to start using TDDs. Take me, for example, I never had >> proper programming education, I'm 17 years old. I know what TDD is but I've >> never used it before. You have to understand TDD is something very >> enterprise-ish and "professional" that "big serious" companies do. >> >> Look, I'm not saying we can't do it or we shouldn't do it or we won't do >> it - I'm just saying you need a better approach to what you're doing. I >> realize how useful and important TDD can be, but many of us might just be >> too busy having fun. >> >> Regards, >> David >> >> PS. I really hope I wasn't rude, I mean all I said in the nicest of ways. >> >> >> >> On Sun, Aug 18, 2013 at 11:58 PM, Daniel Foré <dan...@elementaryos.org>wrote: >> >>> This all sounds great and I think everybody is pro-testing, however I've >>> yet to see a reproduce-able example or a guide regarding any kind of tests >>> being implemented (especially by those extremely vocal about their >>> importance). Not books or articles about why testing is good, but something >>> that actually shows a person how to write tests for their apps. >>> >>> So, as Linus would say, "Talk is cheap. Show me the code." >>> — >>> Sent from Mailbox <https://www.dropbox.com/mailbox> for iPhone >>> >>> >>> On Sun, Aug 18, 2013 at 3:47 PM, Craig <webe...@gmail.com> wrote: >>> >>>> Hi Alex, >>>> >>>> tl;dr: Unit tests are pretty much necessary to have an architecture on >>>> which you can run automatic system-level tests, and if you aren't >>>> automating then testing becomes too impractical. >>>> >>>> When you describe "system tests" you are actually describing what are >>>> called "acceptance tests" or "behavioral" tests ( >>>> http://www.extremeprogramming.org/rules/functionaltests.html). Unit >>>> tests test small units of code such as classes or functions. Traditional >>>> TDD relies primarily upon unit tests, and those are primarily what I'm >>>> referring to. >>>> >>>> One of the primary purposes of unit testing is to ensure good code >>>> architecture. If you don't unit test, you probably won't have good access >>>> points for your acceptance tests (how do you verify that that Gtk.Label has >>>> the correct text when you can only access the top level window?), so >>>> automation will be out of the question. And if you aren't automating then >>>> you can't continuously integrate (running all tests every time a change is >>>> made to the repository in order to find bugs as soon as they are made). >>>> Honestly, if you aren't automating then testing becomes too impractical. >>>> On Aug 18, 2013 5:10 PM, "Alex Lourie" <djay...@gmail.com> wrote: >>>> >>>>> Hi Craig >>>>> >>>>> For the clarification purposes, I'd like to separate 'automatic tests >>>>> (system testst)' and 'unittests'. I consider them different things. >>>>> Unittests are pieces of code that test some other pieces of the code. >>>>> System tests are scripts/code/steps that test that your program (or part >>>>> of >>>>> it) works. Unittests are usually run automatically (by, say, unittesting >>>>> framework). System tests could be run automatically or manually. There >>>>> are, >>>>> sometimes, frameworks for that, but in most cases it's either manual or >>>>> custom developed. >>>>> >>>>> Unittests are (usually) developed by the same developer who developed >>>>> the original code, just as in your TDD example. System tests are best >>>>> developed by external party (such as users). >>>>> >>>>> From here on, I can agree with you on point 1, and the naming. >>>>> >>>>> Basically, we all agree that having *testing *is a good practice and >>>>> a feasible way to manage the complexity of software. But unittesting >>>>> cannot >>>>> test the logical connections between the blocks of code in the program. >>>>> That's the job for system testing. >>>>> >>>>> I don't care how we call it. The more *systematic *testing we do for >>>>> Elementary the better it's going to be, and the more chances we have to >>>>> sustain growth. >>>>> >>>>> So I would just like to see testing implemented. Any kind of it. >>>>> >>>>> >>>>> On Sun, Aug 18, 2013 at 10:56 PM, Craig <webe...@gmail.com> wrote: >>>>> >>>>>> Hi Alex, >>>>>> >>>>>> To correct you on a couple of things: >>>>>> >>>>>> 1. TDD **does not** require you to have all or even several of the >>>>>> tests written before hand. It simply requires you to have the test >>>>>> written >>>>>> for the next change you are about to make. The idea is to write a test, >>>>>> run >>>>>> the test to watch it fail (this helps verify you wrote your test >>>>>> correctly), add the simplest code to make the test pass, run the test to >>>>>> watch it pass (and verify your code additions worked). Then you rinse and >>>>>> repeat. >>>>>> >>>>>> 2. TDD is actually a simplified form of what developers do already. >>>>>> That is, you usually write some code, run your code, then visually verify >>>>>> that it worked. TDD just crystalizes this process in code which can be >>>>>> executed later. TDD isn't hard, so it's well within the capacity of all >>>>>> of >>>>>> our devs; however, it does taking some getting used to. TDD is the best >>>>>> and >>>>>> fastest way to develop quality code and it's the ONLY practical way to >>>>>> raise the ceiling on the amount of code complexity a team of a given size >>>>>> can handle (there is a lot of research and professional heuristics about >>>>>> this). If a developer doesn't have the will to do this, they aren't >>>>>> taking >>>>>> their discipline seriously and, frankly, are a danger to any project that >>>>>> values quality. Besides, I've never met a developer who has hit the >>>>>> complexity ceiling *and* who has practiced TDD who doesn't advocate this >>>>>> kind of testing. >>>>>> >>>>>> With those corrections in mind, I can't see any difference between >>>>>> your first point and "real TDD". I agree that your 2nd point is a good >>>>>> idea. Automated testing can't capture everything, and it's definitely >>>>>> important to have some hands-on testing that we could run through a few >>>>>> times every release. But we should always be working toward automated >>>>>> testing so developers can, you know, develop. >>>>>> >>>>>> >>>>>> On Sun, Aug 18, 2013 at 2:05 PM, Alex Lourie <djay...@gmail.com>wrote: >>>>>> >>>>>>> Ok, I have not added a single line of code to elementary yet, and >>>>>>> gave some decent amount of headache to real devs around here. I have >>>>>>> though >>>>>>> participated in development of many products, small and large, and so >>>>>>> here >>>>>>> it goes. >>>>>>> >>>>>>> TDD in its pure form requires having tests written and ready before >>>>>>> the code is written. Then failing tests are being implemented one by >>>>>>> one, >>>>>>> having the code both tested and working in the end of this process. I >>>>>>> highly doubt that any of Elementary devs have the capacity or the will >>>>>>> to >>>>>>> follow this. Especially, when many of our projects are built using 'try >>>>>>> and >>>>>>> error' methodology, that is they follow the 'Hey! Let's try this!' rule. >>>>>>> Which is awesome, as it allows fast development and really quick release >>>>>>> cycles. >>>>>>> >>>>>>> Now, what I think would fit Elementary much better is simply testing >>>>>>> (yes, that QA thing everyone loves and adores) - the T from TDD, which >>>>>>> is >>>>>>> the most important part. The best way to do that is, of course, to >>>>>>> create a >>>>>>> bunch of automatic tests, but that's not really feasible either. So as I >>>>>>> see it, we can do 2 things: >>>>>>> >>>>>>> 1. Start looking into unittesting as much and as early as possible, >>>>>>> and have devs starting to create tests. This has the benefit of devs >>>>>>> learning to create unittests and having some of the code tested, and >>>>>>> also, >>>>>>> potentially, at some point, it could help moving to real TDD. >>>>>>> 2. Start creating manual test procedures for basic staff. Yes, it >>>>>>> requires a lot of human power and time, but also do translations. This >>>>>>> is >>>>>>> the most boring part of software engineering, but it is the one that can >>>>>>> bring balance to the force. Also, some of these can sometimes be >>>>>>> automated >>>>>>> too, so it's not all that aweful. >>>>>>> >>>>>>> I personally think we need both 1 and 2. I am a strong believer in >>>>>>> testing as means to improve the product. But TDD is probably an >>>>>>> overshoot >>>>>>> in our case. We need to start with *something*, and right now we don't >>>>>>> really have it. >>>>>>> >>>>>>> >>>>>>> On Sun, Aug 18, 2013 at 8:41 PM, Craig <webe...@gmail.com> wrote: >>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> I posted the following message on Google Plus yesterday, but it >>>>>>>> occurred to me that the weekend may not be prime time for checking that >>>>>>>> social network. I think this message is pretty important, so I want to >>>>>>>> post >>>>>>>> it again here: (I apologize in advance for its length) >>>>>>>> >>>>>>>> Congratulations to all the developers who made Luna such a success! >>>>>>>>> You've done a great job and delivered an incredible Linux experience! >>>>>>>>> >>>>>>>>> I know I bring this up periodically, but I'm concerned that Luna + >>>>>>>>> 1 and future releases will take more and more time to release, and/or >>>>>>>>> that >>>>>>>>> you will quickly reach a ceiling with respect to the amount of code >>>>>>>>> we'll >>>>>>>>> be able to maintain before quality degrades. >>>>>>>>> >>>>>>>>> The cause for my concern is the nature of complexity: as software >>>>>>>>> grows (that is, as code is added), bugs grow exponentially (complexity >>>>>>>>> increases exponentially with logic, and bugs grow linearly with >>>>>>>>> complexity). If we don't start working toward solutions that will >>>>>>>>> scale >>>>>>>>> with this problem, we **will** hit a ceiling with respect to the >>>>>>>>> amount of >>>>>>>>> complexity we will be able to support (this means fewer features or >>>>>>>>> less-powerful features). I promise. >>>>>>>>> >>>>>>>>> I know some in the community are working toward this goal, but I >>>>>>>>> think it's going to take a concerted effort on the part of the >>>>>>>>> developers >>>>>>>>> to take this problem seriously. I urge you all to take this problem as >>>>>>>>> seriously as you take the rest of the user experience (because bugs >>>>>>>>> are, at >>>>>>>>> the end of the day, a sharp degradation of the user experience). >>>>>>>>> >>>>>>>>> In my experience, the silver bullet for combating this problem is >>>>>>>>> test driven development. If you look around the software development >>>>>>>>> industry, code is improving, and it's largely because TDD is catching >>>>>>>>> on. >>>>>>>>> And Google is a good role model in this regard (not just for us, but >>>>>>>>> for >>>>>>>>> everyone--they are pioneers of code quality). If you're a developer >>>>>>>>> and >>>>>>>>> you're unfamiliar with TDD, take some time and research it. It will >>>>>>>>> pay >>>>>>>>> dividends immediately. If you have any questions about development, >>>>>>>>> I'm >>>>>>>>> happy to provide my advice as a professional developer. Also, read up >>>>>>>>> on >>>>>>>>> Google's testing strategies (I recommend >>>>>>>>> http://www.amazon.com/Google-Tests-Software-James-Whittaker/dp/0321803027_How >>>>>>>>> Google Tests Software_). >>>>>>>>> >>>>>>>>> You guys are a _great_ UX shop, now let's become a great code >>>>>>>>> shop. I hope this analogy doesn't offend anyone who is passionate >>>>>>>>> about >>>>>>>>> their tech brands, but my advice is this: >>>>>>>>> >>>>>>>>> Design like Apple, develop like Google. >>>>>>>>> >>>>>>>>> I really push you developers to continue to strive to hone your >>>>>>>>> craft the way Daniel and Cassidy (and any other UX designers) are >>>>>>>>> learning >>>>>>>>> to hone theirs. >>>>>>>>> >>>>>>>>> P.S., Sorry for the book, and I hope you all take this as >>>>>>>>> respectful, constructive criticism. _Please_ ask me anything about >>>>>>>>> development, especially with respect to how we can keep quality high >>>>>>>>> using >>>>>>>>> processes rather than sheer developer effort (so as to free you >>>>>>>>> developers >>>>>>>>> to work on interesting problems rather than bug hunting). >>>>>>>>> >>>>>>>>> Thanks for reading, >>>>>>>>> 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 >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Alex Lourie >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Alex Lourie >>>>> >>>> >>> >>> -- >>> 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
