Comments by "" (@grokitall) on "Unit Testing Is The BARE MINIMUM" video.

The people making those arguments are just proving that they don't understand testing, and can't figure out how to do continuous integration. Tdd only pushes towards lots of abstraction when trying to get legacy code under control. The rest of the time it drives towards writing testable modular code with io pushed to the edges of the system, producing self testing code with a thin and thus easily replaceable user interface. While this does move the regression tests to the front of the process, it makes the debugging phase nearly non-existent and what little is left becomes fairly trivial, as does expanding the codebase. The data is already in about which approach between no test, test after and test first produces better results in the form of the dora reports, and it says do more testing earlier and at the right level and get more, better and easier to expand code faster in the long term. It also points to the long term not being that long.
2
@Artoooooor the only problem with that test is the wait instruction. What happens if you are running on the latest, blindingly fast, machine, and your user is running on an older, slower machine. In that case you need to either make the wait longer, and if so by how much, or you have to make the prior function synchronous so that it doesn't return until the write finishes. Personally I would favour the second approach unless you are specifically trying to emulate the timing as well, in which case I would move the wait inside the function call and bookend the function with a timing function to force the wait to be at least however long it needed to be.
1
You call them requirements, which generally implies big upfront design, but if you call them specifications it makes things clearer. Tdd has three phases. In the first phase, you write a simple and fast test to document the specifications of the next bit of code you are going to write. Because you know what that is you should understand the specification well enough to write a test that is going to fail, and then it fails. This gives you an executable specification of that piece of code. If it doesn't fail you fix the test. Then you write just enough code to meet the specification, and it passes, proving the test good because it works as expected and the code good because it meets the specification. If it still fails you fix the code. Finally you refactor the code, reducing technical debt, and proving that the test you wrote is testing the API, not an implementation detail. If the valid refactoring breaks the test you fix the test, and keep fixing it until you get it right. At any point you can spot another test, make a note of it, and carry on, and when you have completed the cycle you can pick another test from your notes, or write a different one. In this way you grow your specification with your code, and is it incrementally to feed back into the higher level design of your code. Nothing stops you from using A.I. tools to produce higher level documentation from your code to give hints at the direction your design is going in. This is the value of test first, and even more so of tdd. It encourages the creation of an executable specification of the entirety of your covered codebase, which you can then throw out and reimplement if you wish. Because test after, or worse, does not produce this implementation independent executable specification it is inherently weaker. The biggest win from tdd is that people doing classical tdd well do not generally write any new legacy code, which is not something you can generally say about those who don't practice it. If you are generally doing any form of incremental development, you should have a good idea as to the specifications of the next bits of code you want to add. If you don't you have much bigger problems than testing. This is different from knowing all of the requirements for the entire system upfront, you just need to know enough to do the next bit. As to the issue of multi threading and micro services, don't do it until you have to and then do just enough. Anything else multiplies the problems massively before you need to.
1
Despite doubling the number of programmers every five years, the need for them is going up even faster. This means that the demand exceeds supply and therefore if the development environment is not good and relies on getting crappy code out of the door fast, you should start looking for a better job as soon as you can. Just make sure in your interview that you ask the right questions to ensure that you are moving to somewhere better before taking the job. A good interviewer will let you ask questions to get a good fit between your needs and theirs, as they won't retain staff if they don't.
1
@davidvernon3119 the success rate isn't great, but the point was mainly that there are more job vacancies than programmers, so you don't need to keep working for a bad employer. obviously being invited to join another company is better, but you don't need to wait for the invite.
1
@wwkw4992 actually, it is not a good idea to create the tests for your own code under two conditions. The first is when the company demands that all testing is done after the code is thrown over the wall to the testing silo.This not only produces worse tests, but makes those tests flakey and fragile. The other time is for writing acceptance tests, when the developer is rubbish at talking with the customer, where you need someone with a clue to extract that information for the developer. In all other cases test first works better.
1
While it might make sense to test the internals of functions in systems programming languages, it still makes more sense to write functional tests of the function API until you absolutely need to test the internals, and then only test those bits you absolutely must test.
1
Yes doing tdd slows down the initial delivery speed, but unless you absolutely need first move advantage to capitalize on the network effect, not doing it usually comes with a much crappier result, and becomes increasingly slower until you move to a test first design. So in that specific use case, you can get some advantage from being first to market, but you are usually better served even in this case doing test first with a minimal viable product and incrementally adding more features.
1
If you need two tests, write two separate tests, but remember that their purpose is different. Unit tests and integration tests are part of the continuous integration stage, and check that the code does what the programmer understood was needed. Acceptance tests are part of the continuous delivery pipeline, and check that the code does what the user actually intended. They tend to be written at different times and sometimes by different people for different purposes.
1
@tongobong1 I would say you can have multiple assets if it is defining a complex precondition, but that this is the only time, and should be discouraged, as this is usually the code smell that you have not done enough upfront thinking about the testing. It is usually better to move all of those assets into separate tests with clear error messages. This is one of the benefits of tdd, in that it naturally moves the logic of the code under test to a more modular form so it ends up easier to test. You only have to test the logic of the module rather than having to muck about testing all of the surrounding glue logic describing where and how to get your test data. It also makes your code more functional, and makes more of it into pure functions which are easy to test.
1
I do know that when they write the code for the space shuttle they used the fact that they had multiple machines that had to agree to put the contract out with multiple companies. When they got it back they analyzed it, and found that a lot of the code had the same assumptions and blindspots in them, which just goes to show that it is much harder to get completely redundant implementations of the same specifications than you think. I'm sorry, but I don't remember the names of the reports and papers which covered it in detail.
1
@ContinuousDelivery this is exactly the correct analogy to use. In science what you are doing is crowd sourcing the tests based upon existing theories and data, and using the results to create new tests, data and theories. Peer review is then equivalent of running the same test suite on different machines with different operating systems and library versions to see what breaks due to unspecified assumptions and sensitivity to initial conditions. This then demonstrates that the testing is robust, and any new data can be fed back into improving the theory. And like with science, the goal is falsifiability of the initial assumptions. Of course the other problem is that there is a big difference between writing code and explaining it, and people are crap at explaining things they are perfectly good at doing. Testing is just explaining it with tests, and the worst code to learn the skill on is legacy code with no tests. So people come along and try to fit tests to legacy code only to find that the tests can only be implemented as flaky and fragile tests due to the code under test not being designed for testability, which just convinces them that testing is not worth it. What they actually need is to take some tdd project which evolved as bugs we're found, delete the tests, and compare how many and what types of bugs they find as they step through the commit history. If someone was being really nasty they could delete the code, and reimplement it with a bug for every test until they got code with zero passes, and then see what percentage of bugs they found when they implemented their own test suite.
1
Tdd comes with a number of costs and benefits, and so does not doing tdd or continuous integration. The cost of doing tdd is that you move your regression tests to the front of the process, and refactor as you go and it can cost up to 35 percent extra in time to market.. What you get back is an executable specification anyone can run to reimplement the code in the form of tests, a set of code designed to be testable with very few bugs, and the combination is optimized for doing continuous integration. You also spend very little time on bug hunting. it also helps with areas that are heavily regulated as you can demonstrate on an ongoing basis that it meets the regulations. All of this helps with getting customers to come back for support, and for repeat business. Not doing tdd also comes with benefits and costs. The benefit Is mainly that your initial code dump comes fast, giving a fast time to market. The costs are significant. As you are not doing incremental testing, the code tends to be hard to test and modify. It also tends to be riddled with bugs which take a long time to find and fix. Due to the problem of being hard to modify, it is also hard to extend, and if they have to get someone else to fix it it can sometimes be quicker to just reimplement the whole thing from scratch. This tends to work against getting support work and repeat business. As for the snowflake code no one will touch, it will eventually break, at which point you end up having to do the same work anyway, but on an emergency basis with all the costs that implies. Testing is like planting a tree, the best time to do it is a number of years ago, the second best time is now. The evidence for incremental development with testing is in, in the dora reports. Not testing is a disaster. Test after gives some advantages initially, while costing more, but rapidly plataus. Test first cost a very little more than comprehensive test after, but as more code I covered you get an ever accelerating speed of improvements and ease of implementation of those improvements, and it is very easy for others to come along and maintain and expand the code, assuming they don't ask you to do the maintenance and extensions.
1
@AndrewSmithDev what you are doing there is exploratory testing to understand the external library. A well written library will separate the core functionality from the user interface, so you can write a test providing your input with your guess as to the output, and correct the test if the result does not match. If the same input gives different outputs to the same input, use a different library because the non-deterministic nature of the library code responses will cause nothing but problems. How will you know if your code using the returned value is correct if you don't know what the returned value will be? The only way around this is to log the input to the library and every respone, and then create lots of tests covering every response to make sure it does not return something daft, and then expect previously unreported values to be returned in production. For most tasks that is a level of risk that is just not worth the costs involved for the value provided.
1
@nschoem that perception definitely exists, and is based upon intuitive feelings that writing tests with your code takes longer, which is true but not really relevant. What happens with feature addicted managers is that they start off saying get the feature to work and we can write the tests later. Then they prioritize the next feature over testing, resulting in no tests, and what few tests do get written are fragile because the only way to test most code that was not designed with tests in mind tend to rely on implementation details to work at all. This results in code with increasing levels of technical debt which gets harder and harder to debug and extend, making everything slower. The only way to fix this is by refactoring your way out of the problem, which needs tests, and test after tests are harder to write and fragile, so you end up writing tdd style tests for the refactored code so you can just delete those original tests as they cease being helpful. You still have to write the tests in either case if you have a long lived or large code base, but tdd style tests first tests tend to be API tests which don't depend on internal implementation details, and thus don't break much.
1
@lucashowell7653 the tests in tdd are unit tests and integration tests that assert that the code does what it did the last time the test was run. These are called regression tests, but unless they have high coverage and are run automatically with every commit you have large areas of code where you don't know when something broke. If the code was written before the tests, especially if the author isn't good at testing, it is hard to retrofit regression tests, and to the extent you succeed they tend to be flakier and more fragile. This is why it is better to write them first. Assuming that the code was written by someone who understands how to write testable code, you could use A.I. to create tests automatically, but then you probably would not have tests where you could understand easily what the test failing meant due to poor naming. When you get as far as doing continuous integration the problem is even worse, as the point of the tests is to prove that the code still does what the programmer understood was needed and document this, but software cannot understand this yet. If you go on to continuous delivery, you have additional acceptance tests whose purpose is prove that the programmer has the same understanding of what is needed as the customer, which requires an even higher level of understanding of the problem space, and software just does not understand either the customer or the programmer that well either now or in the near future. This means that to do the job well, the tests need to be written by humans to be easily understood, and the time which makes this easiest is to write one test, followed by the code to pass the test. For acceptance tests the easiest time is as soon as the code is ready for the customer to test, adding tests where the current version does not match customer needs. Remember customers don't even know what they need over 60% of the time.
1
@temper8281 this is the argument I've heard from everyone who can't write good tests, as well as from those who don't understand why testing matters. If you are just doing a little hobby project which nobody else is ever going to use, and is never going to be extended, then you can mostly get away with not having tests. As the project gets bigger, or more popular, or has more developers you need the tests to stop regressions, communicate between developers, spot coupling, and numerous other things, most notably to deal with technical debt. The more any of those factors rise, the higher the cost of shipping broken code, and thus the more the tests matter. By the time you need continuous integration you cannot do without the tests, but the harder it is to retrofit them to your existing legacy code base, so it is better to learn how to do testing earlier and add it to the project sooner.
1
I find that to be an easy question to answer. Write the test at the next level up only when you have tried to write it at the lower level and found it too hard. More importantly, if you later find that you can test the code using new lower level tests, remove those higher level tests that are redundant and therefore provide no added value. As you will perform new work using tdd,, the refactored new code will be more testable, moving the tests down the levels of the pyramid, until you end up with code using the higher lever tests which is little more than a translation layer to the new functions which exists only to support older code not moved to the newer, more testable API. At this point you can add development comments reporting that the API is deprecated and use whatever the new API is instead, further pushing refactoring of older code.
1
Too big a subject for a comment. It is covered extremely well in Michael feathers book "working effectively with legacy code". However in general, you write just enough of a test wrapper around the code you need to update, use that wrapper to refactor the code to make it easier to update while writing lower level tests for the changes, then do tdd for the new stuff. This takes you from just having a test that asks does it compile and run, to having a set of high level tests of the old stuff with a small but growing tdd base where you can gradually move the tests down the testing pyramid. Remember the code took a long time to get into it's current mess, and it will take a long time to refactor your way out of it.
1
@algernon69 but the idea of being at the edge still applies. Generally you have the stuff you write, the glue logic to ask what they write for the data, and the stuff at the edge. With the stuff you write, write the code in a tdd way so that your stuff is testable. This naturally moves the logic into separate functions which you can easily figure out the test data for, and thus init test. The rest is just how you ask their code for the data you need, which you then pass to your nice testable function, and thus you have moved their stuff to the edge, and in the process produced a much cleaner design.
1
@algernon69 mocks are not easy and are usually a sign that the code was not designed with testing in mind, but splitting your code up this way means that you end up with a lot less code having to be tested inside the mock, which makes the mock easier.
1
If you expect your first draft to be crap, still do tdd to evolve a good API, and use your tests to provide an executable specification of the API. At that point you can either throw away the code, in which case the.number of passing and failing tests gives you a measure of how far you are from fully reimplementing the API, or if your editor or ide can highlight dead code you just put your new code at the start of the function and delete the dead code as it gets made redundant. Because you are testing to the API, there is no reason to implement it using the same set of private functions you used in your first draft, and can refactor the new functions to be better as you generalise your new code.
1
@deanschulze3129 there are reasons behind the answers to some of your questions, and I will try and address them here. First, the reason tdd followers take automated regression testing seriously is that a lot of the early advocates came from experience with large teams writing complex software which needed long development times. in that context, regression tests are not optional, as lots of people are making lots of changes to different parts of the code that they don't know very well. This led to the development of continuous integration, where code coverage for regression testing was essential. Tdd later came along after the development of continuous integration, with the added awareness of technical debt to add refactoring to the continuous integration cycle. You don't seem to understand just how recent the understanding of how to do regression testing is. Even the idea of what a unit test is was not present in the 2012 version of the book "the art of software testing", but it forms the base of the testing pyramid at the heart of regression testing. Also, automated regression testing cannot work unless you get management buy in to the idea that code needs tests, and broken tests are the most important code to fix, which is even harder to get quickly, but all of the tech giants do exactly that. You cannot do continuous integration without it. Even worse, you cannot learn good test practices trying to fit tests to code written without being tested in mind. The resulting tests tend to have to depend on implementation details and are often flakey and fragile, further pushing against the adoption of regression testing. As to statistics, the dora metrics produced from the annual state of Dev ops report clearly indicated that no testing produces the worst results, test after initially provides better results than no testing, but only up to a certain point due to the previously mentioned problems with retrofitting regression tests to code not designed for it, and test first produces ever faster production of code of higher quality than either of the other two. The methodology surrounding the report is given in detail in the accelerate book, by the authors of the state of Dev ops report as they got fed up of having to explain in detail to every new reader they encountered. Bear in mind, the number of programmers doubles every five years, so by definition most programmers have less than five years experience in any software development methodology, let alone advanced techniques. Those techniques are often not covered in training courses for new programmers, and sometimes are not even well covered in all degree level courses.
1