Today i come across this tweet:
// Detect dark theme
var iframe = document.getElementById('tweet-1837055371589955632-848');
if (document....
For further actions, you may consider blocking this person and/or reporting abuse
I've been a professional developer for almost 30 years and have VERY rarely used any form of automated testing.
I've always thought (and seen plenty of evidence) that automated testing very much encourages a siloisation of code knowledge, and really isn't good overall for teams working on a project. To my mind, if you are working on some code - you should UNDERSTAND that code and the ramifications of modifying it. Automated testing encourages a hands off approach and a reliance on the assumption that the tests are 'correct' and up to date - keeping the code being tested very much as a black box, with no real understanding being gained.
Knowledge siloization is bad, but I think the amount of time required to test a software product without automated testing is also bad.
Without any automated tests, people have to ensure an app works. I've seen different people have different thresholds for how much manual testing they consider to be easy. Some people see no issue with complicated and convoluted manual testing setups, like creating 500 line JSON payloads by hand to submit to REST endpoints. In fact, this also can lead to siloization because the knowledge for the test needs to be passed to the next person. If it's not written down and the person leaves, the knowledge gets lost.
One of the benefits of automated tests is the ability to focus on very small pieces of code. I think that at a certain point, the amount of time spent on regression testing can get to be completely unreasonable when everything is done by manual testing.
In fact, I've seen entire teams dedicated to manual testing struggle with keeping track of their tests. Eventually they got to the point where they HAD to come up with an automated solution because they were wasting so much time testing the same things over and over for regression.
Perhaps you can get by without automated testing on some projects, but for massive projects with hundreds of contributors and mission critical operations it's just not possible. At least, that has been my experience.
@code42cate commented about how failure to understand code before changing is a cultural problem. I agree because regardless of manual testing or automated, if people are blindly changing things that's a project management failure rooted in a dysfunctional culture.
Good take
Do you expect every developer, no matter the maturity, to know every single line of code in a project with hundreds of thousands or millions of lines of code?
No, but it's a great idea to have them actually understand the particular code they're working with, and its relationship to the project. Automated testing works against this
I don't see how that is working against it to be honest. If you are blindly changing code just because tests pass, thats not the tests fault but an engineering culture fault imo.
I agree. You change the code knowing full well how it works and the implications. Unit testing is in place for regression testing of the things you may not have considered. Often it's something small and overlooked, but you didn't need a full time team to catch the issue after you've merged
Who ever said "blindly"?
Nobody.
Huh? Not understanding code = blind. Am I missing something here?
I have a counter argument.
In my current company we have a complex price calculator written by a couple of people who have left the company long ago. There is about 1 developer left who understands the price calculation to some degree, and that's it. It's a huge, hot mess and nobody dares touching it because nobody knows what potential ramifications it could have. I dubbed it Frankenstein's Monster.
The learning I took from this is:
And this isn't the only piece of code without tests. Automated testing does make sense in many scenarios. I agree with one thing though - You should not have tests for the sake of having tests, this is nonsense. But I would love to finally put this monster to rest.
I wasn’t expecting this post to grave attention. I agree. Having test just for the sake of having tests isn’t the point. 👍👍
I agree. One possible definition of Legacy Code is code that is not tested and is therefore hard to change, see the book from Michael C. Feathers. You just can't be confident that any change has no undesired side-effects whereas with tests you can at least guarantee that a certain contract still holds.
You are exactly the type of programmer this post is talking about. Having tests doesn't mean that you trust them blindly. It means that you have a way to verify that the code does what you think it does, including edge cases and errors, even if you refactor it, and they should fail if you change the behavior of your code. You have to understand the code AND the tests, and maintain them accordingly. If you don't see value in the tests, I agree with the title of the post: it's a skill problem.
I just refactored some code I wrote a couple of years ago and I love that I codified all the edge cases I wanted it to support so that I can be reasonably confident that even with a redesign, the outputs only changed in the way I expected them to.
This 👆
Building tests increases the confidence for new joiners to get their hands dirty by having proper documentation and guardrails - and a lot of people learn faster by doing instead of reading.
Having this big hurdle to understand everything before being able to to contribute just silos the knowledge to the people that have created it.
There used to be a great article 'don't be a Rick' which I concur - make the barrier to entry as low as possible and get more minds to work on the problem.
Totally backwards, sorry. By testing code you are providing documented, digestible examples of expcected use context and correct system behaviour to people who DO NOT already have that knowledge internally.
If tests need to be updated, they should be. That is equivalent to updating documentation, with the benefit that tests demonstrate where they are wrong by failing. Documentation doesn't do that.
I may not have '30 years' experience, but most of the people you are working with won't either. If you're not testing because of fears of siloization, that's basically equivalent to being the silo, but not knowing it.
I experience almost the exact opposite. When people make changes that break tests, they must then dive in to figure out why their changes broke the tests, and learn more about the system. Tests help them detect and understand how their changes affect the wider system, including parts that they may have incorrectly felt isolated from while working towards their own goal.
But I think part of your point is that tests can make you feel overly secure if you make a change and all tests pass, which I would agree with. No number/quality of tests can free us from doing our due diligence.
Ultimately though I find a solid test suite is much more effective at ensuring quality, compared to projects without tests where developers have to just "stay on their toes", so to speak. The codebases I work in that have automated tests are much more robust, well-organized, and easier to onboard into than the ones that don't. Devs feel much less release anxiety too, because these projects are empirically less likely to break in prod (though it still does happen of course).
I really struggle to understand your argument on how automated testing leads to developers lack of understanding of the codebase.
The tests aren't supposed to pass if someone made a mistake, and in order to fix them, one needs to understand what's wrong.
I see where you are coming from tho. Taking units in isolation leads ignoring adjacent units. However, that's not an excuse! Proper unit testing is supposed to document the code in a very detailed way.
Modularity and parallelism is not siloisation. 30 years developing and you figure you have everything you need. Meanwhile the entire industry shifted under your feet.
Modern design patterns are mandated by volume, and enhanced with portability. You need to reduce the dependency footprint to achieve that.
By automated testing, do you mean like any of unit, integration, e2e tests? If so, isn't automated testing's main value is to replace manual testing, which takes hours of man power and probably does not covering all scenarios such as regression testing? How can you make an argument against automation of manual testing? Unless you're saying that manual testing is also optional.
That's probably the worst take I've read for not implementing automated testing. You try coming into a large, new project and understanding every part of it before making changes.
Automated testing -- presuming you have enough of it -- allows a developer to make changes to implementation with increased confidence that the change won't break anything. If you have coverage data as well (which you should, it's 2024 after all) then you can prove that your code was run as part of the tests.
Is automated testing perfect? No, you have to have enough of it, not every edge case will be thought of and 100% coverage with all tests passing doesn't automatically mean the software is bug free, but it certainly helps and honestly -- it's really not that difficult to implement.
These days if I see a project without automated testing I assume it either isn't a very important project or it's a skill issue.
IME the junior devs are going to roll in blindly wrecking everything in their path, regardless of if you wrote tests or not, spilling their spaghettis everywhere. Tests, which almost all of them written by me, are about the only thing that protects the company from their endless flood of bugs and regressions.
So the difference is whether you want a test suite to find the bugs in 10 minutes or a QA guy to find the bugs in a week or a customer to be the one to discover the bugs at release time.
Interesting point, in a relevant sized codebase what is your approach to tackle code refactoring or changes in logic that span across multiple modules ensuring that everything still works as intended. Also how do you define works as intended for code written by someone else?
In most classes I attend there highly experienced well spoken guy who will make a counter argument for every best practice. Don't be that guy
One of the best ways to UNDERSTAND the code, if not the best, is to write or read a test. You can save yourself some minutes of testing/test reading by executing the code in your head of course, again and again (in allusion to saving minutes of reading a documentation by hour-long debugging).
So your argument is that you've sucked for 30 years, so you're going to continue to?
It's often an issue of priorities and technical debt. I remember middle managers actively prohibiting refactoring and anything connected to it for the sake of quickly shipping features, and I still repeat this pattern in my self-employed business, depending on the customers' priorities and budget, or knowingly increase technical debt to push some urgent quick fixes.
Sometimes it also seems like a vicious circle: before modifying legacy code safely, we should add tests, but before we can add tests, we need to modify the code to make it testable, at least when it comes to unit tests. So we have to approach everything with end-to-end-tests from the outside in many iterations, none of which will be free of risk. And that's a very special skill of testing and handling legacy applications.
You wrote "unit" tests in your headline and then you talk about complex e2e testing.
Second - it is not only a matter of skill, it is also a matter of time. If you come across a large legacy codebase without tests to a team not used to write them, you will very likely never establish them. Because client will keep firing new requirements and you will never have a chance to stop and fix the tech debt.
Disagree. I used to think this way (lack of time) but with current code generation tools… you can step up the thing blazing fast
About the definition of “unit”. Do not stick to the preconception of unit=class , what’s a unit of logic. Let’s redefine unit to a “logical piece that works together” and there you go 👍
We may debate over how doable is to introduce automated testing into project without them, but the definitions of "unit" (independend isolated functions) and "e2e" (interactions between different parts of the system) is pretty much well established and those two should be distinguished.
I’m challenging you to think about the difference between unit and integration 😉
We all agree with the definition of e2e👍
Well...
In my previous post I roughly used is a an equivalent. If you want to be precise, integration is "between two (or a few) parts of the system" and e2e should mean "the whole system".
But I am quite happy with the definition from Vue.js docs - they recognize unit, component (only makes sense in the component-based frameworks though) and e2e. We can discuss more subtle division or even different categories, but the more I am thinking about it, I tend to think it is basically "test without dependencies" (unit) and "test with (mocked) dependencies" (e2e/integration/whatever).
No. Stick to the accepted terms and don’t go off and try to reinvent things. Do not overload the field.
If you're writing new code in a legacy code base then you can at least write tests to cover your new changes. At that point it becomes easier to extend coverage to the rest.
This is a great take and very succinctly put! The tradeoff between writing tests and productivity is not as important as making sure your devs know how to test. Furthermore, knowing how to test will actually improve how you design your components for better maintainability. Your three examples of dependencies making it hard to test is a great example.of this. Lastly, what to test for is probably the most important question and has been discussed a lot.
Thanks! Really appreciated
My thoughts exactly! I would advise the said developer to leave their employer for one who does not allow a merge until tests have passed, if they care about advancing their career in finite time that is.
Agreed! More often than not, it's a lack of skills but also a lack of tooling, or caused by the development culture and leadership of an organization.
Good point in my experience unit testing applies cleanly to OO centric languages. One of the reasons I'm not a fan of Python is that much of the code I see is not testable.
The problem is that a lot of this testing with the mocks and such it may require is harder than development so when you're done implementing the functionality you're not even half done, which is kind of crazy.
agree.
succinct issue here is to tame the mocking-library/test-runner/testing-framework you're using so it's not that hard.
But it's hard! it is.
I literally just had this exact thought. Like, word for word (how dare you steal my thoughts!). In all seriousness, testing is absolutely a skill like almost everything else in software development. It just takes time to learn.
Not writing tests in a new codebase may be only a knowledge/skill issue (e.g., the team doesn’t know how to write tests or doesn’t understand why they should write them). Not writing tests in a legacy codebase, which has none and was not designed to be testable, may also involve more/deeper issues (e.g., culture, priorities, time to refactor, etc…).
Personally, for me, the 3 key aspects of writing tests are:
Asserting the design of the code (e.g., the API is easy to use, the code is loosely coupled, etc…)
Asserting the behaviour of the code (i.e., the code does what it is/was intended to do)
Acting as documentation for others (be it other devs, or QAs, or POs, etc…)
Quoting "The Pragmatic Programmer" by David Thomas and Andrew Hunt: “Testing is not about finding bugs, it's about getting feedback on your code: aspects of design, the API, coupling, and so on. That means that the major benefits of testing happen when you think about and write the tests, not just when you run them.”
As a full stack developer I agree, BUT the better approach in my opinion is to move the responsibility of creating Unit Tests to the testers as they have the Test Cases and that is their primary responsibility. This ensures the tests are more accurate and not built to have a passing result.
Completely disagree. A developer's primary responsibility is to write code that solves the problem given to them. What's an easy way to prove that it solves the problem? Tests.
The QA engineers are another layer of proving that the code is doing what it's supposed to do but not the only layer
This 👆
I disagree, if your developers can't take a TDD approach then they don't know what there expected acceptance criteria is. Integration and end to end testing is the responsibility of the testers to ensure regression issues outside of the changed code are identified.
I am a QA Engineer and there are a few factors like time, resources, culture, skill and maturity to consider if you are going to expect unit testing or xDD from a developer or team or company. I advocate for all forms of testing. We are rebuilding a huge legacy system using the strangler fig pattern. Unit testing leads to testable code and less traps. Coupled with a good QA Engineer and Analyst doing different layers of testing you can become quite confident in a system. It is about team cohesion, understanding, skill sharing. You can have a dev, qae, qaa all testing but have no idea what the others are testing and how, but if they all come together and become sort of a hybrid mega testing mind then they will probably gain a wonderful understanding of their system and be confident in it and understand how it can be modified safely. And let's not forget performance, load, chaos, etc. forms of testing that can even further give confidence and understanding of a system.
Amazed at the number of people disagreeing with this.
I can understand people not wanting to or being able to write tests due to a lack of time.
But believing that it's a bad idea to do so... is... interesting.
I agree to functionally unit tested code. i.e. tests that validate the behavior of the intended usage. For an app it could mean that you extensively test the combinations and permutations of how an end user actually can use the program. Most other tests that I encountered usually locks the implementation and makes the code base rigid and discourage refactoring.
When you find a gap or an issue you try to primarily add it from the user perspective. i.e. a series of clicks with different options to trigger the bug.
It's actually illegal.
What is the "it" that is actually illegal?
Wow. I guess any piece of hot garbage qualifies as an article these days.
It's not always a skill issue. There are other factors like time and top-down pressure from management that don't understand the importance of automated testing.
Some of the scenarios you describe aren't unit tests so I don't think you're in any place to be judging others when you can't even produce an article without grammatical errors.
After dozens of more deep articles I didn’t expect this one to grab any attention tbh 🤷♂️
Now, i challenge you to redefine what’s a “unit”. A class? An object perhaps?
Why not a “unit of logical peace”. Sometimes that peace of logic is divided into 2/3 files and we name the test “integration” … my take is , if you zoom out a little bit , that’s a unit 👍
You're not making sense for a start. Do you mean 'piece'?. When referring to oneself you should capitalise 'I'. Don't try to reinvent the wheel.
A unit test usually tests a specific piece of functionality at its lowest level that is isolated and doesn't depend on anything else. Usually that's a function or the construction of a class.
I think the article grabbed attention because it contains bad advice and a biased argument that holds little to no value in the real world.
👍
I don't subscribe to the time argument. A project should progress faster due to fewer bugs being found if it has good automated test coverage. I do agree teste can take a significant effort to write and run if you don't know how to write testable code, i.e. there is a skills issue.
Love the comment section tbh. Lots of opinions and experience.
Great read 👏
I ask, "If you don't write a unit test, how can you prove your code does what you [the developer] intended? How can some else learn what you intended without have you in reach? How will some else know when a change to either your code, or code on which your code depends, instigates a breaking change, if you don't have the safety net of unit tests". Writing unit tests is like creating the key for the lock, which is your code. They work hand in hand and so is the responsibility of the developer not a tester. The are far more a development (developer) tool than testing when you think about it.
I absolutely agreed. If a developer refuses or is incapable of writing a test for their unit it is a serious skills issue. I would go as far to say they are not software developers but hackers in the old fashioned sense of the term.
As you [reader] can tell, this is a very old gripe of mine. Developers are duty-bound to prove their code does as they had intended. It might not be what the requirement stipulated but unit tests give you the reassurance you can change your code to meet the requirement reassured you understand the impact.
Thanks ! Appreciated
I agree that testing is a skill but it is often implemented wrong. Hear me out.
I also disagree on the point that it acts as a documentation of the code you write. For documentation you can use doc comments directly which can be picked by many tools which can generate static site and can be hosted on GitHub pages for no cost. Even IDEs show these doc comments when you hover over the function or pass arguments.
The main reason I feel unit tests are bad is how we measure them. Most companies measure it by line / branch coverage. Which is bad because it will make developers priorities files which can give more coverage rather than testing essential logic.
And even if these tests fails, we won't know how critical that function is? Is it even being used in some flow? or was it just a util function which is no longer required?
In my opinion, a good way to write tests would be to ask product managers for test cases and their priority for the feature. Then the test should be written to cover these use cases and should also indicate the priority in their name along with the feature.
This way if a test fails, I would know which feature is impacted and I would have better context to fix it as well.
Most problem with software is it is bloated with code that isn’t needed, but now you have to write some unit test to test code that shouldn’t even be in there. Then you got dweeb#1 who over engineers everything and now has to over engineer a unit test to test the dweebs code.. dweeb#2 has to one up dweeb#1 by making his code even more over engineered and the cycle continues.. mix in with dweeb#5 convincing everyone we need the newest mess of javascript to make life easier with unit testing. Next thing you know u got 2 million lines of code that can be deleted and replaced by 1/10th of the lines and have a robust app running and all the dweebs are arguing over some unit testing that needs to be done.
The issue for me has never been skill or knowledge of the benefits. It has always been about velocity. Real world development is often very task oriented with tight time frames and extreme overwork. Then add frequent readjusting of business requirements due to bad business side planning and the value of building and yes maintaining tests gets degraded. I would love to have a platform of great test for every part of the system. It could catch errors of unintended consequences from changes to shared code. It just is not e realistic when the business requirements and thus the tests and code bases can be changed many times in a month with the dev team having little control over this velocity.
What's the velocity when you factor in the necessary manual testing for every deployment? Also fixing defects that unit/e2e would have caught? Automation will save you so much time and busy work so that you can focus on writing new features.
I totally agree with writing automated tests, but don't waste your time on unit tests. Unless the function you are trying to cover is highly complex, in which case, don't write unit tests, spend time on breaking the function down to simpler functions that are easy to read and don't need unit tests. I've written all types of tests for years (I've been developing in various languages for 25 years), and the only tests that didn't help at all were unit tests. At best they usually don't cover everything the function can do, so the coverage isn't useful, and at worst they give false representation that the code as a whole will work. Spend the time on writing integration or end to end tests, they have saved my skin more times than I can remember. And they automatically let you know, for the journeys you are covering, that things actually work. They might be a pain to update, but that pain is worth it for the confidence they give you, and the learning they force you to undertake when working them out.
It's not always a skill issue. Especially in consulting where "just make it work" is the culture, hopping from project to project every couple of months and those existing projects don't have any tests to begin with. Before that I worked in a place where TDD was the culture and we wrote useful tests but also went overboard and wrote some that I felt didn't add value. Ignorant take and a pretty dick way to express your opinion though bruv. Good job.
This 'skill-issue' bit did not make sense to me. I think whether testing is beneficial or not depends on the scale and the design of the project - for example manual testing is the way to go for smaller projects, particularly if there are a lot of dependencies. I only have experience with jest and I'm a total beginner, so I could be wrong
Ironically much of the way that the author is using language indicates that there are still a number of skills to be learned by him. Unit tests are not functional tests of an application. He jumps all over the place on this. It could have been a good article with careful editing and rewriting, instead it’s more like click bait and a rant.
👍
Unit testing is a logical fallacy. There exists a function that transforms code to a unit test therefore we can assert that a unit test is a different view of the code and nothing more.
Customer asks for a function that returns 42
function foo() { return 42; }
expect(foo()).toBe(42)
How would the unit test in this example give you better information than the original code? In the original code I can check for side effects. In the unit test I cannot. The unit test is actually inferior and a lot of bugs come about from people trusting them and believing they have some sort of magical power that they don't.
I guess, we may redefine what does “unit” mean? 🤔
What if we define “unit” to be a greater peace of functionality? Let’s not tie our hands to “file” 👍
I agree with it being a matter of skill and perspective. I also disagree with various comments that tests create siloisation and concentration of knowledge.
Most developers I have have worked with don't really understand the purpose of tests or how to do it properly. Let's summarise some facts:
Given this, it boils down to skills and understanding. With the advent of a plethora of AI tools nowadays there is no excuse not to write tests. AI can at the least help you get out the gate by generating a base set of tests. Developer discretion advised.
It is entirely possible to perform TDD. If you cannot then may it is a skills issue.s
Not always. Hear me out. If you work in an industry where software can't be changed easily then sometimes it's not possible to write unit tests due to bad code architecture. Changing code to be testable can cause bugs in nasty old monoliths.
I agree it is a skill issue but it's just as much a skill of writing easily testable code as it is to write the test itself. It's much easier to test small discrete pieces of functionality than long tangled classes/methods.
We have a global library, that contains 2 directories abstract logic and business logic. For both we have tests/100% coverage (automated). The "applications" feed from the library. The application is manually tested by developer and tester. There is no time and money to write tests for each individual application. This is some sort of middle way ...
That's a place i also lack, will try to learn it
Writing code to check code and assuming that the code you wrote to check the code you wrote doesn't also need checking is moronic!
Well! What have I learned here?
Hi there. as a mern stack developer, i launched my first web. Feel free to submit your feedback if it needs improving
codelabs.uz/