1. #21
    Ext JS Premium Member westy's Avatar
    Join Date
    Feb 2009
    Location
    Bath, UK
    Posts
    928
    Vote Rating
    49
    westy is a jewel in the rough westy is a jewel in the rough westy is a jewel in the rough westy is a jewel in the rough

      1  

    Default


    Agree to many of the sentiments in this thread.
    Fixes need to come faster, and there needs to be more pride in the quality that is put out.
    If that means writing a full blown application to test with then so be it; using the examples for smoke testing is not good neough.

    Still on 4.1.3 here, mainly due to showstoppers in the 4.2 releases I have tried, and partly due to the change to Sencha Cmd imposing changes to how themes are laid out not fitting at all well with how our products and shared repos are structured.
    Hope to upgrade at some point, but way down the list at the moment...
    Product Architect
    Altus Ltd.

  2. #22
    Sencha Premium Member
    Join Date
    Jul 2012
    Posts
    105
    Vote Rating
    32
    jptrainor will become famous soon enough jptrainor will become famous soon enough

      0  

    Default


    Having had bad experiences recently myself I of course noticed this thread.

    Regarding "pride" in work. I'm sure many individual developers take quite of bit of pride in their work at Sencha. But they have multiple large teams no doubt. In a situation like this the fault lies on the management. And I fault Sencha deeply on that front. No single developer can overcome weak management insight into quality, bad process, misplaced priorities, lack of serious automated testing, etc, etc. All those are necessary to maintain quality when software and teams get big. If the ethos is missing in the organization then it's impossible for any single developer, tester, or support person, to remedy it. No amount of bug filing or maintenance releases will help. Everyone suffers - including, customers and the user's of their products as a result. Chronic quality problems with individual developers are easy to deal with - you fire them. The chronic issues at Sencha appear organizational. The management don't care about quality. These analysis are best left simple and IMO that is all there is to it - Sencha management don't care. If they say they do and try hard to convince you of that without demonstrating real change then we have only to consider the evidence before us to conclude that they must be incompetent. The only other explanation would be a hidden agenda. Competent management would recognize this situation, respond seriously, communicate their response, and there would be improvement.

  3. #23
    Sencha Premium Member
    Join Date
    Jul 2012
    Posts
    105
    Vote Rating
    32
    jptrainor will become famous soon enough jptrainor will become famous soon enough

      0  

    Default


    Is that all that happens - smoke testing using the examples? Totally inadequate if so.

    I've asked Sencha to comment on their quality assurances practices. No response so far. They are distracted by their developer conference. Which I find ironic, actually.

    Quote Originally Posted by westy View Post
    ...using the examples for smoke testing is not good enough.

  4. #24
    Ext JS Premium Member westy's Avatar
    Join Date
    Feb 2009
    Location
    Bath, UK
    Posts
    928
    Vote Rating
    49
    westy is a jewel in the rough westy is a jewel in the rough westy is a jewel in the rough westy is a jewel in the rough

      0  

    Default


    Quote Originally Posted by jptrainor View Post
    Is that all that happens - smoke testing using the examples?
    I believe they may have some unit tests of some kind, but in my experience, when presented with a problem, they tend to check one of the examples to see if it works/renders ok.

    I don't believe they have a full blown application that they test with at least, which I think they should.
    Product Architect
    Altus Ltd.

  5. #25
    Ext JS Premium Member tvanzoelen's Avatar
    Join Date
    Apr 2008
    Location
    Groningen - Netherlands
    Posts
    1,118
    Vote Rating
    30
    tvanzoelen has a spectacular aura about tvanzoelen has a spectacular aura about tvanzoelen has a spectacular aura about

      0  

    Default


    The problem with fullblown applications, like also mine, is that it is full of patches since I started with version ExtJs 2.

    Often these previous bugfixes cause problems as well with new releases. These full blown applications are full of history. I can imagine these examples are clean of that.

    But the input of customers should avoid these problems. I still think that version 4.2.1.8+ was released too quickly. The 1.7th was then still in BETA.

  6. #26
    Ext JS Premium Member westy's Avatar
    Join Date
    Feb 2009
    Location
    Bath, UK
    Posts
    928
    Vote Rating
    49
    westy is a jewel in the rough westy is a jewel in the rough westy is a jewel in the rough westy is a jewel in the rough

      0  

    Default


    Yeah, true.
    We have many overrides too, although our latest app started like with Ext 4 developer preview 1.
    Our old Ext 2 apps are staying on that!

    To help with the issue of finding stuff that you have either overridden or copied from src and tweaked (since sometimes you just have to) I wrote a simple function to help:
    Code:
        /**
         * Function that logs a warning in the console if the lastCheckedVersion of a function
         * is less than the current Extx version.
         * Should be wrapped in <debug> tags.
         * @param  {String|Number} lastCheckedVersion The version to check against the current Ext version.
         * @param  {Function} func The function that we are being called from.
         */
        Altus.warnIfExtVersionUpdated = function(lastCheckedVersion) {
            var currentExtVersion = Ext.getVersion('extjs');
            if (!currentExtVersion.match(lastCheckedVersion)) {
                if (Altus.Logging) {
                    Altus.Logging.warn(arguments.callee.caller,
                                       'Method is an override that duplicates code in the framework, so needs checking.',
                                       'Last checked version: ' + lastCheckedVersion,
                                       'Current version: ' + currentExtVersion);
                } else {
                    // Wait for Altus.Logging to be loaded...
                    Ext.Function.defer(arguments.callee, 10, this, arguments);
                }
            }
        };
    Slightly filthy (with the defer), but serves the purpose

    Then use it either at the start of the function where parts of the src have been copied, or in the callback from define, e.g.
    Code:
    Ext.define('Altus.overrides.button.Button', {    override: 'Ext.button.Button',
    
    
        /**
         * Avoid using the horrendous button layout.
         * See here: http://www.sencha.com/forum/showthread.php?243089
         * @type {String}
         */
        componentLayout: 'autocomponent'
    },
    function() {
        // <debug>
        Altus.warnIfExtVersionUpdated('4.1.3');
        // </debug>
    });
    I don't imagine you'll get any dev input in this thread, and if you do it won't be until after the conference.

    Cheers,
    Westy

    PS: Good to be back; not posted on the forums in months!
    Product Architect
    Altus Ltd.

  7. #27
    Sencha Premium Member
    Join Date
    Jul 2012
    Posts
    105
    Vote Rating
    32
    jptrainor will become famous soon enough jptrainor will become famous soon enough

      1  

    Default


    A full test app is useful. It is an integration test. It comes at the end of the process. I suspect there are fundamental absences at the beginning of the process.

    A proper set of regression tests will test individual components from the bottom up. Ideally it produces some coverage information. Although that's tougher to gather in javascript. Good tests will cover all failure cases, all expected corner and edge cases, and will include coverage of every error and exception that can be raised by a module. A big framework like Ext of Touch would have thousands of individual tests.

    When it gets to browser layouts and ui components, you add headless testing techniques.

    When the tests are doing their job they become the place you go to reproduce bugs. The question being not "where in my code is the bug happening" but "how did my tests miss this". Duplicate the bug in a test. Then fix it. The test remains to ensure it stays fixed. It takes some discipline but it pays off big time in software quality dividends. There is no alternative and little middle ground. Where it is embraced quality is great and stays great. Where it is rejected, or ignored, quality enters a tail spin. There is a night and day difference.

    Your QC staff - at the end of the process are making sure the pieces are hanging together as an integrated system. Making sure you are meeting your requirements. Making sure the quality that should be there is there and when it isn't getting down to the root causes to answer why not. They aren't crap rejectors trying to stop junk from hitting the world. That's not QC, that's baby sitting the developers. They aren't controlling quality at that point because there was no quality there to control to begin with. My guess is the most of what I described above is absent at Sencha. That there are QC roles filled somewhere in Sencha, but those individuals are no more than crap detectors who struggle as best they can to keep junk from escaping. But it's an impossible job and it won't produce quality software.

  8. #28
    Sencha User
    Join Date
    Apr 2012
    Posts
    10
    Vote Rating
    3
    tjonut is on a distinguished road

      3  

    Default new version.....new bugs.....

    new version.....new bugs.....


    I saw those problem related to toggle buttons and tooltip component..... but

    what about infinite grid component.

    In 4.1.3. it works without problem ( with a quick fix ).
    In 4.2.1., o my god ...... full of bugs and also Sencha remove a lot of features (add row into a buffer store for examples).
    About the removal of the features, let say it is ok....... but.... about the infinite scrolling bugs.
    I don't understand how this bugs were left in the framework, I mean
    : reload grid function, grid will not work if they are not data to retrive, scroll problem ( I broke their example application ) ..... I mean common.....

  9. #29
    Sencha Premium Member
    Join Date
    Jul 2012
    Posts
    105
    Vote Rating
    32
    jptrainor will become famous soon enough jptrainor will become famous soon enough

      3  

    Default


    I'm in vehement agreement.

    I didn't try the buffered store / infinite grid until 4.2.0 so I don't know if they worked before or not. If they did work in prior release then I take that as evidence that there is no automated testing. Automated testing of lower level libraries, e.g. basic io and a buffering algorithm, is fairly simple. New code shouldn't appear without test coverage and modifications shouldn't appear with out passing the existing tests. Fiddling around manually with example code is absolutely not a substitute.

    If Sencha are trying to maintain their code without a great suite of automated tests then expect more problems. The evidence suggests that they work without that discipline.

    I would have more sympathy if it were some subtle issue of layout or styling or similar in an odd flavour of some old browser that resists test automation. But I have pretty much zero sympathy for what I see here.

    I'm doubly agitated because I have my own exhaustively tested layer of caching underneath all my Ext code and don't even need a buffered store! The grid scrolling would be enough, but by design they appear to have them tightly coupled... (poor design - a whole separate discussion!).

  10. #30
    Sencha Premium Member
    Join Date
    Jun 2008
    Posts
    323
    Vote Rating
    6
    Scorpie is on a distinguished road

      0  

    Default


    I fully agree on jptrainor on this one, i`ve been involved since 2.x and what scares me the most is the fact that I havent seen a test suite bundled together with the ExtJS or Touch framework whatsoever. For me thats a sign that test suites are absent all together.
    I`m from Holland!