Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×
Classic Games (Games) Programming Games

Tetris Is Hard To Test 169

New submitter JackDW writes: Tetris is one of the best-known computer games ever made. It's easy to play but hard to master, and it's based on a NP-hard problem. But that's not all that's difficult about it. Though it's simple enough to be implemented in one line of BBC BASIC, it's complex enough to be really hard to thoroughly test.

It may seem like you can test everything in Tetris just by playing it for a few minutes, but this is very unlikely! As I explain in this article, the game is filled with special cases that rarely occur in normal play, and these can only be easily found with the help of a coverage tool.
This discussion has been archived. No new comments can be posted.

Tetris Is Hard To Test

Comments Filter:
  • One line? (Score:5, Funny)

    by GrahamCox ( 741991 ) on Saturday October 25, 2014 @08:19PM (#48231807) Homepage
    If anybody wrote code like that for me, they'd be made to sit on the naughty step and think very, very hard about what they'd done.
    • You're no fun. If I worked for you, I'd quit as soon as possible.

      Really, who couldn't love code like this:
      0d=d:IFdVDUd:a=POINT(32*POS,31-VPOS<<5):RETURNELSEMODE9:GCOL-9:CLG:O FF:d=9:REPEATVDU30:REPEATGOSUBFALSE:IFPOS=28VDUPOS,15,VPOS,24;11,26:IF0E LSEIFa=0PRINT:UNTIL0ELSEUNTILVPOS=25:v=ABSRNDMOD7:i=0:VDU4895;3:REPEATm= 9-INKEY6MOD3:FORr=TRUETO1:t=rANDSGNt:IFt=rCOLOURv-15:VDUrEORm:i+=m=7AND9 -6*r:IF0ELSEFORn=0TO11:d=n/3OR2EORd:GOSUBFALSE:IF1<<(n+i)MOD12AND975AND& C2590EC/8^vVDU2080*AB
      • Re: (Score:3, Informative)

        Really, who couldn't love code like this:

        Except that is not "one line". It is six lines. Any program can be a "one-liner" if there is no limit on the line length. Well, unless you writing it in Python.

        Also, as long as I am on a rant, Tetris is NOT NP-Hard, since the arrival of the blocks is probabilistic. It is only if the entire sequence of blocks is known in advance that it becomes NP-Hard. But that doesn't happen in actual play.

        • Re:One line? (Score:5, Informative)

          by lgw ( 121541 ) on Saturday October 25, 2014 @09:32PM (#48232117) Journal

          Except that is not "one line". It is six lines. Any program can be a "one-liner" if there is no limit on the line length. Well, unless you writing it in Python.

          The line length limit is 256 bytes, of course. And these hacks are the basic-equivalent of the C obfuscation contest.

          As the authors say: "I'd like to think it is self documenting. The code speaks for itself; even if what it has to say is not very nice."

          • The line length limit is 256 bytes, of course.

            The program is 430 bytes.

          • Re: (Score:2, Informative)

            by Anonymous Coward

            Except that is not "one line". It is six lines. Any program can be a "one-liner" if there is no limit on the line length. Well, unless you writing it in Python.

            The line length limit is 256 bytes, of course. And these hacks are the basic-equivalent of the C obfuscation contest.

            As the authors say: "I'd like to think it is self documenting. The code speaks for itself; even if what it has to say is not very nice."

            And here we get to the core of the problem. The presenter passes off information in an incorrect light, so only the audience that cares to accept it will continue accepting his later statements.

            One of those statements is that code coverage tells you what to test. It doesn't. It tells you what you haven't bothered to test. What you need to test is driven by the user stories, customer requirements, and other bits of development documentation. Testers writing tests for permutations of non-important functio

            • Re: (Score:3, Insightful)

              by Ed Avis ( 5917 )
              It's analogous to testing itself. Testing cannot prove the absence of bugs, though it can find them. Similarly a coverage check cannot show that your test suite is adequate, but it can show it to be inadequate (or perhaps reveal dead code to prune). Nobody is claiming that coverage is the be all and end all of testing. That does not mean it is useless to measure it.
        • by raymorris ( 2726007 ) on Saturday October 25, 2014 @10:06PM (#48232201) Journal

          The fact that probability is involved doesn't mean there's not an optimal strategy, of course, where optimal is defined as "highest expected score" (score X probability). So figuring out an optimal strategy is a hard problem - how hard is it?

          If the probability of a certain series of shapes coming next were 100%, we'd have an NP-hard problem, agreed? Does another probability make it easier or harder? Harder, if anything. That's provable because the probability version can be solved by solving each of the potential series as if each were known. What's harder than NP-hard? It may well still be NP-hard. It can't be of any more solvable complexity class.

          • by phantomfive ( 622387 ) on Saturday October 25, 2014 @10:51PM (#48232353) Journal

            What's harder than NP-hard?

            Intractable.

          • by allo ( 1728082 ) on Sunday October 26, 2014 @04:34AM (#48233041)

            I disagree.
            For a stochastic process your greedy "take the option with the best chance" algorithm may work, it may fail completely, just depending on the random numbers. If you have an stochastic polynomial algorithm, you have a chance to get the same or better expectation value than your "optimize global then choose greedy" algorithm. Both approaches may win or fail, but in the deterministic game the np-complete version always wins, while the "shortcut" version cannot compete. In the stochastic version, the shortcut may be as good as the optimal solution, because you cannot get the global optimum anyway so choosing a local one may be a good choice.

            • As I mentioned, the test of fitness is expected value - the average score of 100,000,000,000 games played with that starstrategy, not the result from one specific, randomly chosen game.

              In Hold'em folding preflop with pocket aces may turn out for the best occasionally, but it's still a bad policy because it will lose more than it will win. The best strategy is the one that does well long term.

              • by allo ( 1728082 )

                Jep, and your strategy gets worse, while another strategy may stay average.

                Assume you flip a coin. heads or tails.

                You NP-complete algorithm knows the sequence.
                The probalistic one just guesses "heads".

                Now the Expectation value of both are Zero in the stochastic case. In the deterministic one its infinite win for the np-complete one and zero for the probalistic one.
                So this is an example, where a perfect algorithm for deterministic data is just as good as another for stochastic data.
                This does not mean, you can

                • Let me see if I correctly understand your point. Are you saying:

                  The best algorithm for a deterministic sequence may be / is NP-hard.
                  Best best algorithm for the stochastic sequence may be different.
                  Therefore, the best algorithm for the stochastic sequence may be easier than NP-hard.

                  That seems to make sense. Until you realize the deterministic sequence IS one case of the stochastic - where the probabilityof a certain sequence happens to be 1.00. If you had a polynomial algorithm for probability X, you could

                  • by allo ( 1728082 )

                    no, you got it only the half way.

                    deterministic:
                    best = np-hard, perfekt
                    other: polynomial, good average

                    stochastic:
                    best: np-hard, not perfect, quality unknown
                    other: polynomial, good average

                    the point is not the runtime complexity, but the result. while the best algorithm cannot be beaten on the det. sequence, it may fail completely (in terms of quality) on a sequence without full information. If you got a good polynomial one with an average result, it may be better for many sequences.

                    one example may be an perfe

                    • So in other words, you're pointing out that you could just not solve it, not come up with the optimum move each time based on expected value. Instead, you could settle for a "good enough" move and sometimes you'd get lucky. This is true.

                      you stated:

                      stochastic:
                      best: np-hard, not perfect, quality unknown
                      other: polynomial, good average

                      You called the first algorithm "best", acknowledging that the best (best long- term average) is NP-hard. The other can't be better than the best (by definition) , so the probl

                    • by allo ( 1728082 )

                      Best is only with respect to the deterministic case.

                      disregard runtime complexity.

                      deterministic:
                      there is a best strategy (A).
                      all other strategies (B) are worse or equal.
                      A stochastic strategy (C) may have a good average quality.

                      stochastic:
                      the deterministic best strategy (A) cannot be perfect anymore, just as no other strategy can.
                      (A) has now unknown quality for a random sequence.
                      (C) still has the same average quality.

                      So there is now a possibility, that (C) may beat (A) in an average over a lot of games. (as a

      • Re: (Score:2, Flamebait)

        by sexconker ( 1179573 )

        You're no fun. If I worked for you, I'd quit as soon as possible.

        Really, who couldn't love code like this:


        0d=d:IFdVDUd:a=POINT(32*POS,31-VPOS<<5):RETURNELSEMODE9:GCOL-9:CLG:O
        FF:d=9:REPEATVDU30:REPEATGOSUBFALSE:IFPOS=28VDUPOS,15,VPOS,24;11,26:IF0E
        LSEIFa=0PRINT:UNTIL0ELSEUNTILVPOS=25:v=ABSRNDMOD7:i=0:VDU4895;3:REPEATm=
        9-INKEY6MOD3:FORr=TRUETO1:t=rANDSGNt:IFt=rCOLOURv-15:VDUrEORm:i+=m=7AND9
        -6*r:IF0ELSEFORn=0TO11:d=n/3OR2EORd:GOSUBFALSE:IF1<<(n+i)MOD12AND975AND&
        C2590EC/8^vVDU2080*ABSr;:t+=a:IF0ELSENEXT,:VDU20:UNTILt*LOGm:UNTILVPOS=3

        Anyone who had to read it, update it, or debug it?
        Anyone who had to play the fucking game (it's full of game-breaking bugs - http://survex.com/~olly/rheoli... [survex.com] )?

      • How long before The Tetris Company sends a notice of claimed infringement to Slashdot's designated agent, claiming that this post and others like it infringes the copyright in Tetris [slashdot.org]?
      • It would be probably shorter in Forth. ;-)
    • If anybody wrote code like that for me, they'd be made to sit on the naughty step and think very, very hard about what they'd done.

      Unless, of course, you were developing for embedded hardware, where you are trying to do way too many things with way too few resources***. Then you'd give that programmer a promotion.

      ***Although those days are gradually coming to an end, as even the tiniest systems are getting more and more resources, and eventually they'll all join the rest of us, where readability, verifiability, and maintainability take top priority. But for now, they're not all quite there yet.

    • by Stanza ( 35421 )

      You've never written code in perl, have you?

    • I'd hire the person in the blink of an eye. That kind of discipline is sorely missing among younger programmers these days.

  • I'm sure there is a joke in there somewhere.

    • 9-INKEY6MOD3:FORr=TRUETO1 --- lol

    • by dj_nme ( 3515255 )
      The joke is the "Tetris in one line of BBC Basic" is a lie, because it causes an error message "line too long, truncated" and then on the pop-up where the program should be running has the error "no such variable". Perhaps false claims shouldn't be made for something which can be tested very easily?
  • by Trepidity ( 597 ) <`delirium-slashdot' `at' `hackish.org'> on Saturday October 25, 2014 @08:22PM (#48231823)

    It may seem like you can test everything in Tetris just by playing it for a few minutes, but this is very unlikely! As I explain in this article, the game is filled with special cases that rarely occur in normal play, and these can only be easily found with the help of a coverage tool.

    Tetris doesn't need coverage tool to test you. Everything about you.

    Code-coverage tool is crutch for weak capitalist engineer. Tetris is Soviet technology, forged by people's will.

    • Tetris doesn't need coverage tool to test you. Everything about you.

      So what you're saying is...

      In Soviet Russia, Tetris game tests you!

  • Nice advertisement (Score:5, Insightful)

    by Anonymous Coward on Saturday October 25, 2014 @08:24PM (#48231831)

    From a company promoting automated WCET analysis. Hah!

  • Though it's simple enough to be implemented in one line of BBC BASIC

    Any language that doesn't require carriage return + linefeed can do anything in one line.

    And Basic comes with a ton of library fuctions that makes things easier to do. No need to initialize memory, dispaly, setup graphic or keyboard interrupts, etc.

    • In this case, a line is no longer than 255 characters. If you never used one of the early toy computers, you won't remember it, but each programming line was typically limited to a certain length.

      And let's not even get started talking about line numbers.
    • by JackDW ( 904211 ) on Saturday October 25, 2014 @08:43PM (#48231917) Homepage
      A BBC BASIC line is limited to 256 bytes, including the line number. It is impressive to squeeze the whole game into that space. There's also a 140-byte Javascript version [i-programmer.info], also very impressive, though it has fewer features and doesn't have all the block types.
    • Well - it does use quite a nifty trick to implement a subroutine, given that you can only GOSUB a line number, and there's only one line number.

    • by jopsen ( 885607 )

      Any language that doesn't require carriage return + linefeed can do anything in one line.

      Exactly... In fact there is a lot of very complicated one-line javascript libraries just download one of those .min.js files :)
      br Seriously, a readable 30 line implementation would have been more impressive...

    • by darkain ( 749283 )

      Maybe you'd prefer a binary version at 256 bytes?

      http://256bytes.untergrund.net... [untergrund.net]

  • by raymorris ( 2726007 ) on Saturday October 25, 2014 @08:28PM (#48231845) Journal

    In BBC BASIC, a colon is a statement terminator, much like a semicolon in languages with C-style syntax. The linked code is therefore not a one-liner by any meaningful definition of the term. One could replace all of the linefeeds in Linux kernel source with semicolons and other appropriate terminators. That wouldn't make the kernel a one-liner.

    • by Nyder ( 754090 )

      In BBC BASIC, a colon is a statement terminator, much like a semicolon in languages with C-style syntax. The linked code is therefore not a one-liner by any meaningful definition of the term. One could replace all of the linefeeds in Linux kernel source with semicolons and other appropriate terminators. That wouldn't make the kernel a one-liner.

      If it's a one-line program, why is it more than one line?

      A line of code is not the same as a line on a screen. The program won't fit on one line on most screens, but it will fit on one line of BBC BASIC, which fortunately has a well defined, but short maximum length of 256 characters. The whole program is 257 bytes as there is an extra byte to mark the end of the program.

      from: http://survex.com/~olly/rheoli... [survex.com]

    • In BBC Basic, a single line is 255 characters. RTFA.
      • A line can be no more than 256 characters. That doesn't mean that the following is one line:

        foreach mammal in pets
        print mammal ' "is a mammal"
        if (is_cat(mammal) {
        print " and also a cat"
        }
        }

        Just because all cats are mammals doesn't mean that all mammals are cats.
        Just because all one-liners are less than 257 characters doesn't mean that all programs less than 257 chara

    • by Splab ( 574204 )

      While I totally agree with the one-line bullshit, I'd just like to point out, that in fact, you can't collapse the linux kernel into a one-line statement this way; Parts of the code is using macros and they will fail if you put them on the same line.

      • by WillerZ ( 814133 )

        So you run cc -E first then

        • by itzly ( 3699663 )
          The nice part about putting the entire Linux kernel on a single line is that you always know the exact line number of the bug.
      • by ignavus ( 213578 )

        While I totally agree with the one-line bullshit, I'd just like to point out, that in fact, you can't collapse the linux kernel into a one-line statement this way; Parts of the code is using macros and they will fail if you put them on the same line.

        #include "kernel.c"

        That's a one liner!

    • by allo ( 1728082 )

      what do you expect from a oneliner? Tetris()? A Perl Oneliner does have semicolons as well.

    • In BBC BASIC, a colon is a statement terminator, much like a semicolon in languages with C-style syntax. The linked code is therefore not a one-liner

      Ignoratio elenchi

  • Though it's simple enough to be implemented in one line of BBC BASIC

    Perlers are so jealous right now; they need 2 lines.

  • by 140Mandak262Jamuna ( 970587 ) on Saturday October 25, 2014 @10:10PM (#48232211) Journal
    Code coverage tool seems like a good idea from some theoretical stand point. But in practice number of code paths multiply rapidly and getting all the paths executed would involve unreasonably long time. Further rarely called procedures or rarely executed is just one class of problems. There are functions that will execute million times correctly and misbehave once in a million or once in a billion calls. For example I came across a bug in something so simple like calculating the centroid of a triangle. Absurdly simply code that adds the x, y, z coordinates of the vertices and divides by 3. That is all. In dealing with output of some CAD software, when the smallest angle of the triangle fell below 1.0e-08 radians, it returned a wrong value of the centroid. Typical sanity checks based on mathematical facts, like centroid of a triangle can never be outside the triangle will not work. The code that checks inside-or-outside of triangle is far more complex than the centroid code. The floating point truncation errors make this kind of sanity check useless. You can't even plot it on the screen and look at the centroid. OpenGL is implemented in single precision.

    So at some point you reach a point of diminishing returns. It might not be worth making sure every line got tested when there are procedures that have a bug that happens in one in a billion calls. My philosophy is, "Perfection is the goal. Doing better than the last release is the shipping criterion".

    • While everything you just said makes sense, nothing beats good testing, and like any tool, this is another one. All that code coverage does is let you focus on what has not been touched, then you'll be able to test it somehow. Also, I could create a similar problem, just like the one you wrote about above and would happen more often. I'm thinking of traffic management in the air. Or maybe even traffic management on land.

      • Just writing a function that properly calculates whether the current year is a leap year would fall into that category as well, since there are exceptions for years divisible by 100 and 400. Thorough testing would be the only way to catch problems within the programmer's lifetime. However, this scenario also validates the parent poster's point - there are times when "good enough" is perfectly acceptable even though there may be logical flaws within the code. Simply doing a mod 4 on the year will likely b
      • All that code coverage does is let you focus on what has not been touched, then you'll be able to test it somehow.

        The trouble is that what you really need to test isn't how much coverage of the code you've got, but how much coverage of the possible input space. More specifically, you ideally want to know that each distinct combination of inputs that will cause a different type of behaviour in the code has been considered.

        Of course, this is typically an implausibly difficult problem to solve in real world projects. To see why, consider that this article proudly claimed that finding the special case of clearing 4 lines t

        • by itzly ( 3699663 )
          Also, it isn't sufficient to know that the execution has gone through the "4 lines cleared twice in a row" code, but somebody should then also watch the score to see if it was actually updated by the correct amount.
        • by JackDW ( 904211 )

          You're right, this sort of testing should really be about covering the range of possible inputs. But that is typically impossible. There are too many possible scenarios. You need a practical substitute.

          I agree that statement coverage is quite crude, it tells you very little about the data being processed. There is more detailed information being produced here - "MC/DC coverage" - which does tell you whether conditional statements have been thoroughly exercised, because each possible reason for the "true" o

          • FWIW, I agree with almost everything you wrote. I have nothing against coverage tools, and I use them occasionally myself. I just think it's important to have a realistic view of the benefits you do and don't receive.

            The only thing I disagree with is your final paragraph, where you talk about safety-critical code. If you really were working on systems where a failure would have catastrophic consequences, I would hope you had a QA process a lot more sophisticated than running a test suite and this kind of co

            • by JackDW ( 904211 )

              If you really were working on systems where a failure would have catastrophic consequences, I would hope you had a QA process a lot more sophisticated than running a test suite and this kind of coverage tool to check for problems!

              Oh, certainly! The good news here is that the avionics industry knows this, and in any case, the FAA won't let them cut corners. I don't know exactly how the industry uses our tools, but it's typically in conjunction with lots of manual testing, with the coverage tool capturing d

          • You know, I like what you wrote since it brought up a safety issue once I read about. It was about a plane making a crash landing, and the pilots heard a "GONG" sound, they were never trained for that sound, but they were able to find it in the manual. It seemed that that gong sound was the sound of everything is failing including redundancy. Now that gong sound is in all the simulations.

            So I look at it as a tool, a tool to test all the code and see if it works in general for most situations, then test agai

  • by rs1n ( 1867908 ) on Saturday October 25, 2014 @10:21PM (#48232251)
    Why would you only test your code via normal use? Why wouldn't you just create a test suite that actually tests all the scenarios? In the case of tetris, you can simply force a sequence of pieces that will enable you to reach the scenarios described in the article. Or you can even start the game with a pre-made board.

    Has slashdot really become a means for tech companies to inject free advertisement by a simple blog post made to look like real journalism?
    • Why wouldn't you just create a test suite that actually tests all the scenarios?

      Defining all of the possible scenarios is often a lot harder than it looks. There aren't too many UI coders out there that haven't said "yeah, we need to fix it, but what made the user decide to do that?" at one time or another.
      • Defining all of the possible scenarios is often a lot harder than it looks. There aren't too many UI coders out there that haven't said "yeah, we need to fix it, but what made the user decide to do that?" at one time or another.

        This reminded me of a UI bug I discovered in Steam - if you have 2 monitors, one rotated 90 degrees, but not the primary, and try to maximize steam on that window, bad things happen.

        Seeing as how I've seen only like 3 people doing that, most not in a home setting, I don't think it comes up much.

        • by Mal-2 ( 675116 )

          Add me to the list of those using this configuration in a home setting, unless you need to exclude me for actually having three monitors -- one is a TV that is usually off or being used for other purposes. (Having both AGP and integrated graphics active at the same time is... interesting. I get lots of odd behavior out of it.)

    • Has slashdot really become a means for tech companies to inject free advertisement by a simple blog post made to look like real journalism?

      Why, did you not get enough :CueCats [wikipedia.org] and i-Openers [wikipedia.org]? This is hardly the first Slashvertisement, and it's the only one from this company that I've seen.

    • by JackDW ( 904211 )

      Thing is, you need both your own test suite and a coverage test tool. The two work together. The coverage tool tells you if your tests are incomplete, helping you to fix them.

      If I were actually testing Tetris I would definitely do it the way you suggest: a pre-arranged sequence of blocks and a pre-programmed series of moves. I'd run the game with that sequence, then look at the coverage data to see if I needed to add anything. Some of the process can be automated, but the test cases themselves have to be m

    • Because it's much cheaper to give the game to some voluntary beta testers (or nowadays... early buyers) to do some normal use testing than to pay a programmer to force a sequence of pieces or premake a board?
  • by Anonymous Coward on Saturday October 25, 2014 @10:30PM (#48232287)

    The article makes it sound like coverage tools help! If you're not familiar with them, they tell you which bits of code have been run, not how many of the N cases of that code have been executed.

    So the code might fail with a particular combination of inputs, but the coverage tool is more interested in which bits of the code have been execute.

    It's one of these tools and metrics that non-technical managers use to substitute for an ability to read code.

    • So the code might fail with a particular combination of inputs, but the coverage tool is more interested in which bits of the code have been execute.

      This is quite true, but at least it's something that can help. Programmers already make enough mistakes, so any help is welcome. Whether that help is worth the price tag in dollars and time has to be determined on an individual case by case basis.
      • by Anonymous Coward

        All of my best testers have been people who use the product to do the job it was intended for, and that means they're testing the same common pieces of code through every use case. The coverage tool is simply the wrong metric, it assumes one use-case = one piece of code, and treats code as 'covered' if its been run because it doesn't know about the use cases.

        Worse, the testers end up trying to run obscure code simply to get the right test metric. So all the belt-and-braces checks I put in to prevent future

    • Validation is way more important than writing code. Coding is grunt work that literally anyone can do. There is a huge demand for programmers, and very few are "good" programmers, 90% are just grunts who will never get any better, and that's life due to demand. So you need validation. I wrote and managed RTL development for 15 years at Intel and code coverage is simply mission critical. No other way around it.

      If you think being able to "read code" is enough to see all the corner cases, you're either very yo

  • It's a piece of cake... http://bitbar.org/blocks/cake.html?fields=9 [bitbar.org]
  • Just one line in the summary gives it away:

    As I explain in this article, the game is filled with special cases that rarely occur in normal play, and these can only be easily found with the help of a coverage tool.

    This doesn't seem like news to me! I'm shocked and appalled!

  • by Neo-Rio-101 ( 700494 ) on Saturday October 25, 2014 @11:15PM (#48232409)

    It's a 15 liner.
    Note that the {CBM-x} represents the graphic on that particular key (press the c= key and the letter to produce it)

    1 a$="efijefijefijefijbfjnhijkbfjnhijkijfgaefjijfgaefjefjkiefbefjkiefbbfjidefj"
    2 a$=a$+"abeieijkaeijijkgabfjiefgehijebfj@abe@dhe":o=207:dime(o):forx=0to111
    3 print," {CBM-M}"," {CBM-G}":p=asc(mid$(a$,x+1)):e(x)=(pand3)+(pand12)*10:next:m=2024
    4 print," {CBM-T}{CBM-T}{CBM-T}{CBM-T}{CBM-T}{CBM-T}{CBM-T}{CBM-T}{CBM-T}{CBM-T}":gosub6:goto7
    5 pokei+e(r),c:pokei+e(r+1),c:pokei+e(r+2),c:pokei+e(r+3),c:c=160:r$="d":return
    6 i=1152:r=h:c=32:gosub5:j=int(rnd(0)*7)*16:r=j:gosub5:r=h:h=j:i=i+9:return
    7 gosub6:w=i:t=i:g=r:k=240:l=1278
    8 gosub15:c=32:gosub5:r=-r*b-g*notb:g=r
    9 i=w:w=i+40:gosub5:gosub15:ifbthen12
    10 getk$:g=randkor((r-4*(k$="s"))and15)
    11 t=w:w=w+(k$=l$)-(k$=r$):l=l+40:goto8
    12 c=o:gosub5:m=m-(l0:w=-t*b-w*notb:l$="a":return

    • 13 fors=ltol+(m-160-l)*qstep-1:pokes+11,peek(s-29):next:y=y-q:m=m+q*40:z=z+q
      14 l=l+40*not-q:next:print"{home}";z:goto7
      15 b=0:forx=0to3:b=bor1andpeek(w+e(g+x)):next:b=b>0:w=-t*b-w*notb:l$="a":return

      {home} is the home character blob (appears as reverse S character) within quotes

      Use A,S,D keys to rotate and drop the blocks
      Have fun!

  • So, on the one hand, it's sort of a spammy/advertisey thing to begin with.

    On the other hand, I'm also not entirely convinced that the code coverage tool really solves the problem, because a given line of code can have different effects under different circumstances.

    If you read in an address from a text stream, and then write to the memory location denoted, that's just one line of code executing that dereferences the pointer, but good luck determining what it does on all future invocations based on watching

    • by wrook ( 134116 ) on Sunday October 26, 2014 @04:55AM (#48233085) Homepage

      Code coverage tools will not tell you if your tests are sufficient. They simply tell you what lines of code were hit. They don't tell you whether or not the line of code was hit while doing a meaningful test. In fact, it is trivially easy to write "tests" that exercise 100% of the code but have no expectations at all.

      What code coverage tools tell you is what code you definitely haven't tested. If you haven't run that line of code in your tests, you definitely haven't tested it. This is useful information, but not essential if you have a good team. My current team is quite comfortable writing tests. We do most things TDD and without trying hard our average code coverage is 96%. I occasionally wander through the other 4% to see if it is worth testing and most of the time it isn't. Occasionally I will find the odd piece of logic that was jammed in hurriedly without tests, but on our team it is quite rare. On the other hand, I have worked on teams that were not comfortable writing tests and mostly wrote them after writing production code. On those teams we would get about 75% test coverage with holes you could drive a bus through. A code coverage tool was very useful for educating people on the need to improve the way they wrote tests.

      I feel very confident I could TDD my way through a tetris implementation and get 100% code coverage without undue effort. I don't think I would find all of the corner cases without help, though. A code coverage tool wouldn't help me in that instance.

  • My dad and I wrote a BBC BASIC interpreter for PC-DOS. I'll have to dig it out and see if I can get this working in it.

  • you didn't write it correctly. TDD.

Those who do things in a noble spirit of self-sacrifice are to be avoided at all costs. -- N. Alexander.

Working...