Comments by "" (@grokitall) on "TDD Is A BROKEN Practice" video.

  1. Your comment demonstrates some of the reasons people don't get tdd. First, you are equating the module in your code as a unit, and then equating the module test suite as the unit test, and then positing that you have to write the entire test suite before you write the code. This just is not how modern testing defines a unit test. An example of a modern unit test would be a simple test that when given the number to enter into the cell perform a check to see if the number is between 1 and the product of the grid sizes and returns a true or false value. For example your common sudoku uses a 3 x 3 grid, requiring that the number be less than or equal to 9, so it would take the grid parameters, cache the product, check the value was between 1 and 9, and return true or false based on the result. This would all be hidden behind an API, and you would test that given a valid number it would return true. You would then run the test, and prove that it fails. A large number of tests written after the fact can pass not only when you run the test, but also then you either invert the condition, or comment out the code which supplies the result. You would then write the first simple code that provided the correct result, run the test, see it pass, and then you have validated your regression test in both the passing and failing mode, giving you an executable specification of the code covered by that test. You would also have a piece of code which implements that specification, and also a documented example of how to call that module and what it's parameters are for use when writing the documentation. Assuming that it was not your first line of code you would then look to see if the code could be generalized, and if it could you would then refactor the code, which is now easier to do because it already has the regression tests for the implemented code. You would then add another unit test, which might check that the number you want to add isn't already used in a different position, and go through the same routine again, and then another bit of test and another bit of code, all the while growing your test suite until you have covered the whole module. This is where test first wins, by rapidly producing the test suite, and the code it tests, and making sure that the next change doesn't break something you have already written. This does require you to write the tests first, which some people regard as slowing you down, but if you want to know that your code works before you give it to someone else, you either have to take the risk that it is full of bugs, or you have to write the tests anyway for continuous integration, so doing it first does not actually cost you anything. It does however gain you a lot. First, you know your tests will fail. Second you know that when the code is right they will pass. third, you can use your tests as examples when you write your documentation. fourth, you know that the code you wrote is testable, as you already tested it. fifth, you can now easily refactor, as the code you wrote is covered by tests. sixth, it discourages the use of various anti patterns which produce hard to test code. there are other positives, like making debugging fairly easy, but you get my point. as your codebase gets bigger and more complex, or your problem domain gets less well understood initially, the advantages rapidly expand, while the disadvantages largely evaporate. the test suite is needed for ci and refactoring, and the refactoring step is needed to handle technical debt.
    8
  2. Everything is taught using easy examples. The reason is simple. If you try and teach using real world large problem examples then it becomes less about what you are trying to teach, and more about the detailed understanding of the large problem you are using as your example. So what a good teacher will do is look for the simplest example possible which still allows you to demonstrate as many details as possible of the thing you are trying to teach. If it turns out a specific aspect doesn't work with that example, look for another one that covers as many of the remaining details as possible. It is for just this reason that every new way of doing AI in games starts by examining how it works with tic tac toe and moves on to harder examples as needed. Because you already know the problem space, you can spend all of your time looking at the potential solution and trying to understand the techniques involved.
    2
  3. The context switching is actually one of the points of tdd. You are constantly validating that your regression test fail, then pass with passing code, then using the refactoring step which is now easy as you have the tests to handle the technical debt. All the while you are discouraging habits which produce hard to test, coupled and in other ways legacy code. As a side effect you end up with a validated test suite for continuous integration, code which you know passes, new code going into version control which you know works and so do the tests that go in with it, and debugging becomes easier due to the smaller changes. You also end up with high code coverage, testable code, a starting set of examples for writing your documentation, and lots of other benefits.
    2
  4. That one is actually quite easy to answer if you look at how GUI code has been historically developed. First, you write too much of the UI which does nothing. Second, you write some code which does something but you embed it in the UI code. Third, you don't do any testing. Fourth, due to the lack of testing, you don't do any refactoring. Fifth, you eventually throw the whole mess over the wall to the q & a department, who moan that it is an untestable piece of garbage. Sixth, you don't require the original author to fix up this mess before allowing it to be used. When you eventually decide that you need to start doing continuous integration, they then have no experience of how to write good code how to test it, or why it matters. So they fight back against it. Unfortunately for them, professional programmers working for big companies need continuous integration, so they then need to learn how to do unit testing to develope regression tests, or they will risk being unproductive and risk being fired.
    1
  5. I think there is also an issue with how tdd is presented, partly preaching to the choir. A lot of those opposing tdd do not have the same definitions as the ci and tdd community. They oppose unit testing because to them a unit is a complete module, and the unit test is every test in the suite to test the module. Similarly they write the entire module, and only write regression tests when they have to, and adding tests or security or portability after the fact is always a nightmare. Because they don't write tests first, their code coverage is minimal, often consisting of UI tests and end to end tests which are fragile, and invert the testing pyramid. A lot of them come from the windows ecosystem or from the object orientation community, where the definitions don't match.
    1
  6. And yet every technique has this same issue. You cannot explain the new technique without working on small, manageable demonstrations. If you try anything else, you quickly get bogged down in the problem details, and obfuscate how the method is actually supposed to work, You can only move on to your example when you have a clear understanding of the method, to try and get better understanding of how and why it works, but first you have to understand how to do it.
    1
  7. ​ @Aleks-fp1kq because they see it as paying 30% extra. The same management will probably also really dislike refactoring, and will probably like the feature treadmill, while not getting that ignoring all the things mentioned slows down the ability to implement features. In all of these cases you are just moving stuff you will have to do anyway in any codebase above a certain size to the front of the process where it will make the biggest difference, which is why you do it first.
    1
  8. ​ @Storytelless first, you separate out the code that does the search, as it is not part of the ui, and write tests for it. Then you have some ideas as to what parameters you want to pass to the search, which are also not part of the ui, and add tests for those. Finally, you know what those parameters are going to be, which hints at the ui, but you have the ui build the search query, and test that that query is valid. Only after all of this is it necessary to finalise the shape of the ui, which is a lot easier to test due to all of the other stuff you have already removed. The ui should be a thin shim at the edge of the code which just interacts with the user to get the parameters. This was it is easier to replace it with a different one if your ui design changes, because you have already removed all of the other stuff which is ui dependent. You can then test the ui using one of the guides test frameworks, just looking to see if the automated step you have recorded actually selects what you expected it to and returns the correct value.
    1
  9. Not only is there the issue of not testing the private api, but there is also the issue that people from the oop community regard a unit as equivalent to the module, and thus the unit test to them is the entire test suite for that module, which is not what a unit test actually is.
    1
  10. No, they see unit testing as cumbersome because they don't write the tests first, then write legacy code which is not designed to be tested, and then write implementation dependent tests which are fragile against the newly written legacy code. All testing of legacy code is cumbersome, a total pain, and an exercise in frustration. This is why you write the test first, so you do not write the legacy code in the first place. However this is a skill, and as Dave pointed out, when you first try it you try and write the test for the imaginary legacy code, and find you are not getting the advantages.
    1
  11. ​ @Storytelless so you write a test tool to run all of your cross platform stuff against which reports when some piece of code will cause a problem in a particular supported browser. This linter will initially just parse the code, but as you find nasty browser specific corner cases, you flag them up, and run this linter over your code before checking in the change. I've done this with html since windows 95, reporting browser specific problems, so the code just does not get checked in in the first place.
    1
  12. I think that what we need here is a test like jez humble's continuous integration test, but for tdd. Most of the criticisms I see can be sumerised as "I write legacy code and don't get the testing pyramid, unit testing or regression tests, so why would test first regression testing make sense". As they don't get regression testing, they also fundamentally don't get refactoring, continuous integration or technical debt. Time for them to learn some of the basics of the industry wouldn't you say?
    1
  13. ​ @evgenyamorozov no, it won't compile, but you are designing the public api, so it does not need to. Once you have an api call which is good enough, you have your failing test, which fails by not compiling, so you create a function definition which meets that api, and a minimal implementation which returns whatever value your test requires, thereby compiling and passing the test. Then you come up with another example which returns a different result, which then fails, and make just enough changes to the implementation to pass both tests. Then keep doing the same thing.
    1
  14. One of the points of test first is that it gradually migrates the code you write into a more testable format, which naturally produces a more functional design, especially when you can make them pure functions with no side effects. Dave made the point in other videos that testable code and legacy code look very different. This is because the legacy code is not designed to be testable, and thus is a total pain to test. It is like trying to retrofit security into an insecure application, you can do it, but it is not pleasant.
    1
  15. ​ @vanivari359 what you described is no more tdd than long lived feature branches which are seldom integrated are Ci. What you are describing is a lot of mandatory testing of the internal api's of internal functions, whereas tdd works in an implementation independent method against the public api's of public functions. You then get the code coverage that your system needs not by testing the internal functions, but by using them from the public api, and having them return results that make sense. The bits which do not get used are then either potential dead code, or part of a more general implementation of a library that you only need some of the functions provided. In either case, as you are working at the public api, you are completely free to totally change how the stuff behind the curtain works. If it is a problem, either you are testing implementation, or you are not coding to pass the tests, in which case you are not doing tdd.
    1
  16. Actually they are mostly complaining about having to start writing regression tests and having to write testable code when they could previously write untestable garbage and force q & a to have to deal with it. Regression testing shines a light on how bad your code is, and they don't like it as they like to think that due to spending some time programming they must be good at it. Test first they hits you in the face with how bad you are at testing, which is not taught, and tdd's refactoring step shows just how much copy past coding is in your code base. Understandably a lot of people who never had to do testing don't like it and push back, mostly with comments which can be paraphrased as "I only know how to write legacy garbage, so it doesn't work for me", not realizing that this is what they are saying.
    1
  17. Testing works best for code which has no side effects, and ui work is basically founded on top of side effects, so you have to already have some skill at testing to even consider writing tests for ui stuff and expecting them to work as well as they do for pure functions. Learn tdd against some non ui coding project, and then apply what you learned to the ui work. This will encourage you to separate the true ui stuff from everything else, and make both easier to test. This is not to say don't test ui stuff, only that you need to get above a certain level of skill in testing to do it well.
    1
  18. Not only that, but when you break the API you feel the pain before your users even find out about it, which just goes to show that a lot of framework and core library developers are not doing regression testing and continuous integration.😂
    1
  19. ​ @Jadestonk sure they do, but eventually someone else has to come along and fix up their legacy code mess to keep it working. This is one reason not allowing check in of code without tests generally improves the code base, but of course the same people will also produce rubbish tests because they never leared how to test.
    1