Reputation
439
Top tag
Next privilege 500 Rep.
Access review queues
Badges
2 6
Newest
 Yearling
Impact
~17k people reached

  • 0 posts edited
  • 0 helpful flags
  • 32 votes cast
Nov
12
comment Are (database) integration tests bad?
In contrast to the last line of your first paragraph--Integration tests should give extra confidence if you are concerned about these kind of random "sunspot" failures, because hopefully you are testing the parts of your code that are designed to recover from those errors gracefully!
Nov
12
comment Are (database) integration tests bad?
Good explanation of the limits of complex mocks, like using another language to mock SQL. When test code gets complicated enough that it seems like it needs to be tested itself, that's a QA smell.
Nov
12
comment Are (database) integration tests bad?
@JeffBowman Point taken on the comment vs. answer, although I was commenting specifically on the Testing Pyramid, which some people do take as gospel (even if you don't). But why do you put "contrarian school" in quotes as if it's a matter of opinion or a joke? Cem Kaner and like-minded engineers and academics are highly regarded members of the software testing community.
Nov
3
comment Are (database) integration tests bad?
... consequently, Fowler et al., in arguing that less effort should be spent on integration tests and user acceptance tests because they are too difficult to write in a robust and maintainable way, are really just providing an ex post facto excuse for why they haven't figured out how to test well at higher levels.
Nov
3
comment Are (database) integration tests bad?
A contrarian school of software QA, the context-driven testing movement, is in part devoted to disputing that there exist any such useful general rules of thumb as the Testing Pyramid. In particular, the seminal texts of the movement give many examples where integration tests are far more valuable than other kinds of tests (because they test the system in context, as a system)....
Nov
3
comment Are (database) integration tests bad?
+1 for "A test that is a perfect mirror of its implementation isn't really testing anything at all." All too common. I call this the Doppelganger Antipattern.
Sep
22
comment What are the benefits of dependency injection in cases where almost everyone needs access to a common data structure?
+1 for a concise answer focused on maintenance issues. More P:SE answers should be like this one.
Sep
16
comment Is there any practical trick to remember the difference between big-endian and little-endian?
@Nevermind I stopped reading that article after the second paragraph. "Of interest only to compiler writers and people who have to deal with memory mapped to registers"? Besides the fact that that's an awful garden path sentence, it implies that code that deals with registers is an edge case. Try using a computer sometime without device drivers.
Jun
10
comment What is the “type” of data that pointers hold in the C language?
C++ pointers to members aren't memory addresses? Sure they are. class A { public: int num; int x; }; int A::*pmi = &A::num; A a; int n = a.*pmi; The variable pmi wouldn't be much use if it didn't contain a memory address, namely, as the last line of the code establishes, the address of member num of instance a of class A. You could cast this to an ordinary int pointer (although the compiler would probably give you a warning) and dereference it successfully (proving that it is syntactic sugar for any other pointer).
Jun
4
awarded  Yearling
May
28
comment Is it good that testers are competing to see who opens more bugs?
Upvoted for the idea that measuring QA productivity by number of bugs found is equivalent to measuring programmer productivity by lines of code written (or story points closed). Both are ridiculous but both persist in the minds of PHBs who can't see any more subtle way to quantify performance.
May
28
comment Is it good that testers are competing to see who opens more bugs?
@Atsby In the sentence you quote, the first clause is a relative statement (find the largest fraction of bugs), and the second is absolute (find the largest number of bugs). It's the difference between saying fill this bucket 90% and fill this bucket with 1/2 gallon when the bucket holds 1 gallon.
Jun
4
awarded  Yearling
Feb
11
answered Thread safe GUI programming
Jul
8
comment Is Python Interpreted or Compiled?
@S.Lott: Calling the tokenization process that Applesoft and '80s BASIC interpreters did "bytecode compilation" is more than a little disingenuous. Yes, the program code entered by the user was stored in memory in a compressed form, one byte per reserved word, but nothing was done beyond that until you typed RUN. It was as if you had a compiler that did the lexing step and then output a stream of tokens that had to be reparsed every time the program was run. Not at all like modern bytecode compilation as done by, say, javac, which encompasses lexing, parsing, and optimization.
Jul
4
comment Is fewer lines of code always better?
@ruakh: No, because debuggers typically allow you to set a breakpoint on a particular line, but with no finer-grained control than that. In Juann's example, if you are confident that MethodThree is working, but want to step into MethodTwo and examine the code that produces result2, you can set a breakpoint on the second line, run the program, and end up precisely at the problem area. With the single-line version you could still set a breakpoint at that line, but you'd then have to step through the call to MethodThree to end up at the same placeā€”a little more clumsy.
Jul
4
comment Is fewer lines of code always better?
+1 for the observations that any modern compiler is going to optimize out the intermediate variables, so there's no performance penalty, and that the multiline version is easier to debug.
Jul
4
comment Is fewer lines of code always better?
@AndréParamés: Read Susan Lammers' Programmers at Work and you'll get a pretty good idea of Gates' abilities as a programmer. He was great at squeezing performance and space in 8-bit assembly language. The last piece of code he wrote all by himself was the ROM BASIC for the TRS-80 Model 100, again in hand-optimized Z80 code. His skills may be dated but there's no doubt he had them.
Jul
4
comment Is fewer lines of code always better?
Not if your manager is judging your productivity by how many lines you write per day! (Some still do, sadly...)
Jun
28
awarded  Commentator