On Sat, Dec 06, 2014 at 03:53:16PM +0000, Russel Winder via Digitalmars-d wrote:
> 
> On Sat, 2014-12-06 at 07:24 -0800, H. S. Teoh via Digitalmars-d wrote:
> > 
> […]
> > Oh, certainly I'm not expecting *all* tests to be automated -- there are some things that are fundamentally non-automatable, like testing look-and-feel, user experience, new feature evaluation, etc.. My complaint was that the lack of automation has caused QA to be completely occupied with menial, repetitive tasks (like navigate the same set of menus 100 times a day to test 100 developer images, just to make sure it still works as expected), that no resources are left for doing more consequential work. Instead, things have gone the opposite direction -- QA is hiring more people because the current staff can no longer keep up with the sheer amount of menial repetitive testing they have to do.
> > 
> > If these automatable tests were actually automated, the QA department would have many resources freed up for doing other important work -- like testing more edge cases for potential problematic areas, etc..
> 
> On the plus side, a couple of organizations have had me in to teach their development staff Python so they can write scripting components for their UI, and teach their QA staff Python so they can script all the menial stuff testing away. Worked very well. So well in one case that the QA staff were able to have breaks and relax a bit and do really high quality end-user testing. HR thought they were slacking so sacked half of them. I think the other half of QA have now left and the product testing is clearly suffering relying solely on automated tests that are not being properly updated.
[...]

The blessing of bureaucracy at its pinnacle. :-)

There is some sign of movement in my current job in the QA department towards automation, but AFAICT it still hasn't taken strong hold yet, judging by the skimpiness of QA test coverage in the code changes I submitted. One of my changes actually passed QA testing but my manager during code review caught a negated if-condition that ought to have caused major test failure. How it managed to pass testing is beyond my imagination... but it's clear that test automation still has a long ways to go around here.


T

-- 
Error: Keyboard not attached. Press F1 to continue. -- Yoon Ha Lee, CONLANG

On Sat, Dec 06, 2014 at 03:48:42PM +0000, Russel Winder via Digitalmars-d wrote:
> 
> On Sat, 2014-12-06 at 07:14 -0800, H. S. Teoh via Digitalmars-d wrote:
> > 
> […]
> > Oh, I *know* there are Javascript testing frameworks out there... the problem is convincing people to actually incorporate said tests as part of the development process. Sure, *I* can run the tests with my own code changes, but there are 50-100 developers working on the project who are also constantly making changes, and unless they also regularly run unittests, the whole exercise is kinda moot.
> 
> If the team is 50 to 100 programmers 1 of whom thinks testing is a good idea then I can see an unmitigatable disaster looming and the technical bosses (*) being sacked. Best bet, get a new job now.
> 
> 
> (*) management and accounting bosses never get sacked, because it is
> never their fault.
[...]

Disaster *looming*? Haha... disaster has been *happening* for the past how many years now... Hence my earlier references to regressions spiralling out of control and new features breaking old ones like there's no tomorrow, and developers scrambling like mad to fix them all in a whack-a-mole bid to bash the product into shippable form by the deadline, of which we tend to be informed the week of (or sometimes, the Friday afternoon before a Monday deadline)...

Fortunately(?), no one has been sacked yet. Part of it may have to do with the fact that practically all our customers are corporate, and corporate customers tend to value business relationships and deals above actual product quality, even when they're on the receiving end. (Just my cynical guess, though. I have no concrete evidence of this. :-P)


T

-- 
Computers aren't intelligent; they only think they are.

On Saturday, 6 December 2014 at 15:14:23 UTC, H. S. Teoh via Digitalmars-d wrote:
> On Sat, Dec 06, 2014 at 08:46:58AM +0000, Paulo Pinto via Digitalmars-d wrote:
>> On Saturday, 6 December 2014 at 08:26:23 UTC, Brad Roberts via Digitalmars-d
>> wrote:
>> >On 12/5/2014 11:54 PM, Paulo Pinto via Digitalmars-d wrote:
>> >>On Saturday, 6 December 2014 at 01:31:59 UTC, deadalnix wrote:
>> >>>Code review my friend. Nothing gets in without review, and as won't
>> >>>usually don't enjoy the prospect of having to fix the shit of a
>> >>>coworker, one ensure that coworker wrote proper tests.
>> >>
>> >>Good luck making that work in companies.
>> >>
>> >>Code review is something for open source projects and agile
>> >>conferences.
>> >
>> >I've worked at several companies, both large and gigantic, and it's
>> >worked very well at all of them.  Code reviews are an important part
>> >of healthy and quality code development processes.
>> 
>> Maybe I have worked at wrong companies then.
>> 
>> In 20 years of career I can count with one hand those that did it, and
>> most developers hated it. Never lasted more than a few meetings.
> [...]
>
> Huh, what...?? Meetings? For code review??? How does that even work...?
>

Easy, the meetings get scheduled with each developer getting a module for review.

Those developers then print the code and get some days for review until the meeting.

The meeting takes place and afterwards each developer updates its own module witb the gathered feedback.

The scenario you described I have only seen live in startups.

I never saw a corporate institution care about code review, specially if the projects have offshored teams, as the ratio is usually 10:1.

On Sat, Dec 06, 2014 at 04:43:56PM +0000, Paulo Pinto via Digitalmars-d wrote:
> On Saturday, 6 December 2014 at 15:14:23 UTC, H. S. Teoh via Digitalmars-d wrote:
> >On Sat, Dec 06, 2014 at 08:46:58AM +0000, Paulo Pinto via Digitalmars-d wrote:
> >>On Saturday, 6 December 2014 at 08:26:23 UTC, Brad Roberts via
> >>Digitalmars-d
> >>wrote:
[...]
> >>>I've worked at several companies, both large and gigantic, and it's worked very well at all of them.  Code reviews are an important part of healthy and quality code development processes.
> >>
> >>Maybe I have worked at wrong companies then.
> >>
> >>In 20 years of career I can count with one hand those that did it, and most developers hated it. Never lasted more than a few meetings.
> >[...]
> >
> >Huh, what...?? Meetings? For code review??? How does that even work...?
> >
> 
> Easy, the meetings get scheduled with each developer getting a module for review.
> 
> Those developers then print the code and get some days for review until the meeting.
> 
> The meeting takes place and afterwards each developer updates its own module with the gathered feedback.

Whoa. People actually do that??! If that's how code reviews are carried out, I can totally see why it wouldn't work. While I'm OK with spending 15-20 minutes reviewing a prospective code diff to be merged into mainline, reviewing an entire module would take up way too much time, and would be too quickly invalidated (as more changes pile up) to be of any long-lasting value.

Some of the code I work on contains files with 4000+ lines of code (sometimes up to 8000+ lines); printing that would fill a small book, and would take at least a week (if not more!) to thoroughly review. By then, the review would be worthless 'cos the 50 other developers have been making changes for a *week*. That's 40 hours * 7 days * 50 developers = 14000 man-hours worth of work. While not all of the work would touch a single file, enough of it would touch code related to that file, that will make any static code review essentially worthless by the time it's done. Such an approach cannot possibly work in today's scale of software projects.


> The scenario you described I have only seen live in startups.
> 
> I never saw a corporate institution care about code review, specially if the projects have offshored teams, as the ratio is usually 10:1.

If "code review" means the process you describe above, yeah, I can totally see why!!

My employer can't be accurately described as a startup anymore, as it has grown to thousands of employees worldwide over the past 10+ years of its existence. But despite all the other flaws I often bemoan, code review is something ingrained in company culture. If code that passes through the review protocol I described still ends up being of such inferior quality as I witness every day, then I truly dread seeing what it turns into when there is no review process at all!! (Or not... I guess it would just be IOCCC all over again on a larger scale. :-P After all, I *did* write a monstrosity that won an ignoble award from the IOCCC once... so I just have to get used to doing that on a regular basis. :-P)

In any case, the only code review process that I can see having any chance of being practicable is review per change request. Reviewing by module is simply not feasible in today's kind of software development, esp. where large teams are involved.


T

-- 
We've all heard that a million monkeys banging on a million typewriters will eventually reproduce the entire works of Shakespeare.  Now, thanks to the Internet, we know this is not true. -- Robert Wilensk

The majority of corporations I have worked for, software development is not their main business, so they tend to disregard anything that doesn't contribute to their business as waste of money.

I imagine your employer main business is software development.

--
Paulo

On 12/6/2014 7:12 AM, H. S. Teoh via Digitalmars-d wrote:
> However, all this level of review kinda loses a lot of its effectiveness
> because we have no unittesting system, so regressions are out of
> control. :-(  The code is complex enough that even with all this review,
> things still slip through. The lack of automation also means QA tests
> are sometimes rather skimpy and miss obvious regressions. Having
> automated unittesting would go a long ways in improving this situation.

Without the dmd compiler test suite, making progress with the compiler would be simply impossible.

On Sat, 06 Dec 2014 16:43:56 +0000
Paulo Pinto via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> Easy, the meetings get scheduled with each developer getting a module for review.
> 
> Those developers then print the code and get some days for review until the meeting.
> 
> The meeting takes place and afterwards each developer updates its own module witb the gathered feedback.
what a mess! the thing i really don't want to do is to have a work where thay have all those useless "meetings".

On Saturday, 6 December 2014 at 16:23:46 UTC, H. S. Teoh via Digitalmars-d wrote:
> On Sat, Dec 06, 2014 at 03:48:42PM +0000, Russel Winder via Digitalmars-d wrote:
>> 
>> On Sat, 2014-12-06 at 07:14 -0800, H. S. Teoh via Digitalmars-d wrote:
>> > 
>> […]
>> > Oh, I *know* there are Javascript testing frameworks out there...
>> > the problem is convincing people to actually incorporate said tests
>> > as part of the development process. Sure, *I* can run the tests with
>> > my own code changes, but there are 50-100 developers working on the
>> > project who are also constantly making changes, and unless they also
>> > regularly run unittests, the whole exercise is kinda moot.
>> 
>> If the team is 50 to 100 programmers 1 of whom thinks testing is a
>> good idea then I can see an unmitigatable disaster looming and the
>> technical bosses (*) being sacked. Best bet, get a new job now.
>> 
>> 
>> (*) management and accounting bosses never get sacked, because it is
>> never their fault.
> [...]
>
> Disaster *looming*? Haha... disaster has been *happening* for the past
> how many years now... Hence my earlier references to regressions
> spiralling out of control and new features breaking old ones like
> there's no tomorrow, and developers scrambling like mad to fix them all
> in a whack-a-mole bid to bash the product into shippable form by the
> deadline, of which we tend to be informed the week of (or sometimes, the
> Friday afternoon before a Monday deadline)...
>
> Fortunately(?), no one has been sacked yet. Part of it may have to do
> with the fact that practically all our customers are corporate, and
> corporate customers tend to value business relationships and deals above
> actual product quality, even when they're on the receiving end. (Just my
> cynical guess, though. I have no concrete evidence of this. :-P)
>
>
> T

+1,000

( D scope should be smaller than C. JRE/CLR should be of limits.
Also this one dude(Linus) talks about a big lang(C++) and it's advocates:
- http://harmful.cat-v.org/software/c++/linus
I'm sure he he has no credibility /s )

On 6/12/2014 5:45 a.m., Dicebot wrote:
> In my opinion OOP is very unfriendly for testing as a paradigm in general. The very necessity to create mocks is usually an alarm.

I am curious how you would write tests without mocks.

> That's 40 hours * 7 days * 50
> developers = 14000 man-hours worth of work.

Poor guys, working 7 days a week, 40 hours a day...