Comments by "MrAbrazildo" (@MrAbrazildo) on "How To Build Quality Software Fast" video.

  1. 1) They will be likely to fail at compile-time, which is fast to fix. 2) Just simple tests, in and out. 3) A change in the code can lead to a bug that once passed in a test. If it's automated, that old test will run again, accusing failing.
    2
  2. I've been made manual tests. I'll try automated tests. 7:09, about those 2, I use to force the simplicity of the code: don't use virtual stuff, avoid classes when f() is enough, avoid global variables, and so on. Except for optimization, I don't engage in unnecessary complex structures. Inheritance only in 1 chosen direction: generic to specific or less to more data.
    2
  3. He said quality and speed use to walk together, despite this being counter-intuitive. You can work a bit faster in the dirt, but if you never clean the workplace, some day you will need to pay your debt.
    2
  4.  @Luxalpa  Games is a very tricky field, however. Some tests will call f()s that depend on several variable states, outside them (called f()s). It's a common scenario in games. And many games have "continuous computation", using numbers with "precision", which is hard to predict. A bug can arise in the middle of the found path.
    2
  5. I believe you are working in the same kind of project, over and over, just with different details. For games, making 1 says little about making another.
    1
  6. A few times in life I solve bugs by just refactoring the code. I should improve that technique, but I don't know from where to start.
    1
  7.  @Luxalpa  "tests are part of normal code"? Not if they are independent f()s, as this channel use to say. I use to put them inside the normal f()s, but I admit this pollutes the code, and removing them would cost time. And certain values should be approved only when combined with others (a character should not run against a wall). These kind of situations won't be prevented by your normal testing code - at least in games, they are too many.
    1
  8. ​ @timmartin325  Repeatability is relevant because, as I said: "3) A change in the code can lead to a bug that once passed in a test". I agree that human tests catch bugs that are impracticable by automated tests. Once I noticed a bug that took 2 years to arise, in a user point of view. It was caused by an overflow in some bits of a variable, that had pass through an optimization rework. That was expected, indicating the hit on the wall. However, the variable worked with +1 for reading and -1 for writing, to fit the bits field. Outside the class, a local variable (representing the field) in a f() work with the values normally. So, when hit the wall, some tasks were made, and the value has been writing back to the var. The point is that later I implement future checks for that memorized value, but it was wrote not with the overflow value anymore (because it wouldn't fit) - instead of it, a reset value due to bit truncation. But this was not enough to raise the bug, because the +1 for reading make it come back to an acceptable value, at the beginning. And combining that with certain characters alignment, consequences passed to be acceptable in a broken geometry: starting (only) from the end (triggering the overflow), completing it at the beginning! (Geometry could be broken, but the alignment should stay in the same direction) . So the victim became unmovable. Plus, a bad luck of characters too close hid the cause. To appear, it has to attend to several steps: the overflow not entirely solved locally, the reset (which could crash or lead to absurd) being hidden by the +1 (for read), some specific alignments, certain characters, starts with character(s) in the "wall", complete it with character(s) at the beginning. And a bad luck make me took more time than I should. I solve it fast, however - I may be inspired. I baptized it as Age of Aquarius Bug: "When the moooooon is in the 7th Hooooouse And Jupiter aligns with Mars Then peace will guide the planets And loooOOOOve WILL STEER THE STARS!"
    1
  9. TDD for each single line, as he said, seems to me a bit overwhelming for complex code. But you can use the unity tests instead: write your algorithm, note some results, and later write a tiny f() that just call it, demanding known input-output pairs. But not all apps you will have to run it to know the input-output pairs. In a board game, you know exactly what should happen, most of the time - at least about the game rules.
    1