Why... why the fuck do people write unit tests and then comment out the god damn fucking assertion lines....
Like what the flying fuck? Cool, we can get some code coverage marks but for fuck sake actually let your tests do their fucking job!!!

Oh, the asserts fail?
Well fucking sort that shit out instead of commenting them out.

I don't get it, if you're going to write tests, fucking test something with them, or we'd be better of without them.

Day of the interview sr. Architect says: "We have near 100% unit test coverage in our code."

One month later when I tell him there are 0 unit tests written against 300 projects: "Yeah, I knew that was a problem."

What can you do when the people who want to hire you lie outright to your face?

Oh yeah, and not a god damned one was written using any sense of object oriented programming at all. Every single damned project is written like its on a motherfucking punchcard put together by a cs 101 student with a 2 hour fucking deadline.

I can understand if it needs some work, just tell me. Don't fucking lie to me just to get me in the door to fix a problem you know you have. JUST HAVE SOME FUCKING RESPECT FOR YOUR CANDIDATES AND DON'T FUCKING LIE TO THEM!

Off to drink some scotch and think about what it would be like to shove a finger deep enough into my nostril to hear a pop and smell popcorn before going off into that good night.

I said good day.

When you are running some unit test cases with less code coverage

Wanna have 120% code of code coverage? Start writing test for unit tests.

I don't get it why there are so many people out, that think testing stupid model classes with getters and setter is needed.

Dude. There is no logic in this class ... it's pure data that gets not modified there (well except if you call the setter)

I've wasted way too much time writting useless unit test because some ppl want to masturbate on 100% code coverage 🤦🏻‍♂️

I just want to share this:

When I start working at my last job, I have little idea of what a unit test was.

My boss on one meeting said that unit testing will be mandatory (wich is ok and umderstandable).

Almost a *year* after that, no one still care about them. I see myself doing them the best I can, but I saw things like wrap the assertion line with "try / catch" to lie to the coverage and unit test percentage. Or in other cases directly uploading *manually* the code on the server without test at all.

And then, as the only developer who do the unit test ok I have to do the missing ones and repair the fake ones.

Then when something explodes the question all the managers love to ask "Did we had the testing?"

At least I quit... that job was some crazy shit, this is just one story of many.

Like that other time that my co-workers did not understand why I needed to do POJOs on an android app because the big bad JSON that the app used was working fine....

I started my actual gig as CTO of construction group (Innovation Hub) a year ago. And it was a hell of a ride, implementing kind of a scrum-ban for project management, XP, peer-reviews, a git-flow, git commit message formats, linters, unit testing, integration tests, etc...
And it's the fun part because with the CIO we had to drive the board to do A LOT of changes in their IT/Innovation drive.

But in one year there is a lot of KPI that went up :
* Deployment: When I arrived it took three stressful days to deploy a new version of one application, once a month. Today we do it every week, and it takes three annoying hours.
* We had no test. NOTHING! Today we have 85% code coverage for the unit test, and automatic integration tests run by our CI server every day.
* We had almost no documentation. Today our code is our documentation (it automatically extracted and versioned).
* We had 0 add value in the use of git. With commit messages as "dev", "asked task", inside jokes and a lot of "fix" and "changes". Today we have a useful git, and we even use it to create our deploy changelogs (and it's only mildly annoying!).
* More important, the team is happy! They get their purpose, see betterment in their tech mastery. They started doing conception, applicative architecture, presentations, having fun.

There is still a LOT of bad things we are still working on, and trying to solve (support workflow and betterment). But seeing what they already did, I'm so proud of my TEAM! I'm a fucking asshole, workaholic, "just do it" kind of guy. But they managed to achieve so much. Fucking PROUD!!

Fucking fuck sonarcloud and everything about it. Part of the build pipeline for us to deploy code is to ensure that 90% of the code is covered by a unit test. Great in theory, horrible in practice. You think you've written enough tests that actually add value and test a valid piece of functionality but NO, sonarcloud throws a fucking fit because you're at 89.888 then your branch is going nowhere. Because everyone else gets to this stage and writes just enough tests to get the coverage to 90.01% then it becomes a stand off of who will break first; the code coverage threshold or your mental state.

During one of our 'pop-up' meetings last week.

Ralph: "The test code the developers are checking in is a mess. They don't know what they are doing."

ex.
var foo = SomeLibrary.GetFoo();
Assert.IsNotNull(foo);

Fred: "Ha ha..someone should talk to HR about our hiring practices. These people are literally driving the company backwards."
Me: "I think unit testing is complete waste of time."
- You could almost see the truck hit the wall and splatter watermelon everwhere..took Ralph and Fred a couple of seconds to respond
Fred: "Uh..unit testing is industry best practice. There is scientific evidence that prove testing reduces bugs and increases code quality"
Ralph: "Over 90% of our deployments are rolled back because of bugs. Unit testing will eliminate that."
Me: "Sorry, I disagree."
- Stepping on kittens wouldn't have gotten a worse look from Fred and Ralph
Fred: 'Pretty sure if you ask any professional developer, they'll tell you unit testing and code coverage reduces bugs.'
Me: "I'm not asking anyone else, I'm asking you. Find one failed deployment, just one, over the past 6 months that unit testing or code coverage would have prevented."
- good 3 seconds of awkward silence.
Ralph: "Well, those rollbacks are all mostly due to server mis-configurations. That's not a fair comparison."
Me: "I'm using your words. Unit tests reduces bugs and lack of good tests is the direct reason why we have so many failed deployments"
Boss: "Yea, Ralph...you and Fred kinda said that."
Fred: "No...we need to write good tests. Not this mess."
Me: "Like I said, show me one test you've written that would have prevented a rollback. Just one."
Ralph: "So, what? We do nothing?"
Me: "No, we have to stop worshiping this made up 80% code coverage idol. If not, developers are going to keep writing useless test code just to meet some percent. If we wrote device drivers or frameworks for other developers maybe, but we write CRUD apps. We execute a stored procedure or call a service. This 80% rule doesn't fit for code we write."
Fred: "If the developers took their head out of their ass.."
Me: "Hey!..uh..no, they are doing exactly what they are being told. Meet the 80% requirement, even if doesn't make sense."
Ralph: "Nobody told them to write *that* code."
Boss: "My gosh, what have you and Fred been complaining about for the past hour?"
- Ralph looks at his monitor and brilliantly changes the subject
Ralph: "Oh my f-king god...Trump said something stupid again ..."

At that point I put my headphones on went back to what I was doing. I'm pretty sure Fred and Ralph spent the rest of the day messaging back-n-forth, making fun of me or some random code I wrote 3 years ago (lots of typing and giggling). How can highly educated grown men (one has a masters in CS) get so petty and insecure?

Developer just emailed our team a complaint that our logging assembly was resulting in their poor test coverage and they sent a change request to give them the ability to mock the underlying log provider (ex. from the event log to ‘something else’).

Looked at their tests, and they are testing whether or not the .Log was executed (on an exception, if the .Log method was not executed, the test failed), which seemed a bit worthless because we’ve already got coverage in our unit tests.
We had a meeting to discuss the issue.
Me: “I’m OK with changing the logging code if it’s necessary, but I want to understand why.”
DevA: “Logging errors is crucial to the database transaction. If someone removes the logging, the tests should fail.”
Me: “If someone removes the error logging on purpose, then they likely have an agenda and will remove the test validation too. It wouldn’t be an accident.”
DevA: “That’s not my problem. They will have to deal with HR.”
Me: “We purposely prevented someone from intercepting the logging just for that purpose. Your test code already covers the business rule, testing the logging seems out of place. That would like writing a test to make sure the System.IO.File.ReadAllText actually reads all the text from a file. You kinda assume a few smart Microsoft engineers already wrote tests for that.”
DevA: “Yea, I guess that would be silly.”

Got cc’ed an email a little bit ago from DevA to his boss..
“We’re not going to be able to change logging assembly. This may have some impact on our overall test coverage as those lines of code will not get testing coverage. You will have to let the DevMgr know we will not meet our test coverage goals.”

WTF!

This started as an update to my cover story for my Linked In profile, but as I got into a groove writing it, it turned into something more, but I’m not really sure what exactly. It maybe gets a little preachy towards the end so I’m not sure if I want to use it on LI but I figure it might be appreciated here:

In my IT career of nearly 20 years, I have worked on a very wide range of projects. I have worked on everything from mobile apps (both Adroid and iOS) to eCommerce to document management to CMS. I have such a broad technical background that if I am unfamiliar with any technology, there is a very good chance I can pick it up and run with it in a very short timespan.

If you think of the value that team members add to the team as a whole in mathematical terms, you have adders and you have subtractors. I am neither. I am a multiplier. I enjoy coaching, leading and architecture, but I don’t ever want to get out of the code entirely.

For the last 9 years, I have functioned as a technical team lead on a variety of highly successful and highly productive teams. As far as team leads go, I tend to be a bit more hands on. Generally, I manage to actively develop code about 25% of the time to keep my skills sharp and have a clear understanding of my team’s codebase.

Beyond that I also like to review as much of the code coming into the codebase as practical. I do this for 3 reasons. I do this because as a team lead, I am ultimately the one responsible for the quality and stability of the codebase. This also allows me to keep a finger on the pulse of the team, so that I have a better idea of who is struggling and who is outperforming. Finally, I recognize that my way may not necessarily be the best way to do something and I am perfectly willing to admit the same. I have learned just as much if not more by reviewing the work of others than having someone else review my own.

It has been said that if you find a job you love, you’ll never work a day in your life. This describes my relationship with software development perfectly. I have known that I would be writing software in some capacity for a living since I wrote my first “hello world” program in BASIC in the third grade.

I don’t like the term programmer because it has a sense of impersonality to it. I tolerate the title Software Developer, because it’s the industry standard. Personally, I prefer Software Craftsman to any other current vernacular for those that sling code for a living.

All too often is our work compiled into binary form, both literally and figuratively. Our users take for granted the fact that an app “just works”, without thinking about the proper use of layers of abstraction and separation of concerns, Gang of Four design patterns or why an abstract class was used instead of an interface. Take a look at any mediocre app’s review distribution in the App Store. You will inevitably see an inverse bell curve. Lot’s of 4’s and 5’s and lots of (but hopefully not as many) 1’s and not much in the middle. This leads one to believe that even given the subjective nature of a 5 star scale, users still look at things in terms of either “this app works for me” or “this one doesn’t”. It’s all still 1’s and 0’s.

Even as a contributor to many open source projects myself, I’ll be the first to admit that have never sat down and cracked open the Spring Framework to truly appreciate the work that has been poured into it. Yet, when I’m in backend mode, I’m working with Spring nearly every single day.

The moniker Software Craftsman helps to convey the fact that I put my heart and soul into every line of code that I or a member of my team write. An API contract isn’t just well designed or not. Some are better designed than others. Some are better documented than others. Despite the fact that the end result of our work is literally just a bunch of 1’s and 0’s, computer science is not an exact science at all. Anyone who has ever taken 200 lines of Java code and reduced it to less than 50 lines of reactive Kotlin, anyone who has ever hit that Utopia of 100% unit test coverage in a class, or anyone who can actually read that 2-line Perl implementation of the RSA algorithm understands this simple truth. Software development is an art form. I am a Software Craftsman.

#wk171

That feeling when your newly added calculation module now has 93% code coverage in unit tests, with the client working on a test case for the last bit.

Killing people is bad. But, there should be a law to allow killing people who don't write proper unit tests for their code. And also those "team leaders" who approve and merge code without unit tests.

Little backstory. Starts with a question.

What is the most critical part of a quoting tool (tool for resellers to set discounts and margins and create quotations)? The calculations, right?
If one formula is incorrect in one use case, people lose real money. This is the component which the user should be able to trust 100%. Right?

Okay. So this team was supposed to create a calculation engine to support all these calculations. The development was done, and the system was given to the QA team. For the last two months, the QA team finds bugs and assigns those to the development team and the development team fix those and assigns it back to the QA team. But then the QA team realizes that something else has been broken, a different calculation.

Upon investigation, today, I found out that the developers did not write a single unit test for the entire engine. There are at least 2000 different test cases involving the formulas and the QA team was doing all of that manually.

Now, Our continuous integration tool mandates coverage of 75%. What the developer did was to write a dummy test case, so that the entire code was covered.

I really really really really really think that developers should write unit tests, and proper unit tests, for each of the code lines (or, “logical blocks of code”) they write.

I got assigned to work on a new project a couple of weeks ago. We got the POC code handed off from senior management, since he came up with the idea over the weekend. The project concept is hella exciting, but the dev manager and PO I have to deal with make life unbearable to say the least.

We have only 2 devs (including me) and 1 QA on this supposedly very important project. Of course, management announced the project to the clients already, so now we have to deliver ASAP cause it adds “sizzle”.

The MVP deadline is... no one knows when, either July 30th or September 1st. The MVP requirements are... unknown. I swear if someone saw the list of tasks and issues attached to “MVP” Epic, they would call us nuts trying to fit it all in.

To make things better, each PR requires 2 reviewers, so we end up adding manager as a reviewer just cause we need him to hit that “approve” button. So in attempt to make life easier, we requested to have a third developer. We are getting another developer, but that guy doesn’t know how to unit test a pure function...

Current priorities are... unit testing with coverage of 95% and if we want to refactor code, we have to add area to the list in a Google Doc. As a result, we are not tackling big things like risk of SQL injections not to mention big features like i18n (5-6 languages to support by the way and yes, it’s part of MVP as well as SSR no one knows why). Currently, I spend 2-3 hours a week in calls with the team just to figure out what the hell MVP is, what we have to do and why we have to do it. Last time we spent an hour refining 1 spike and breaking down one story into 3.

Oh, we also don’t have a deployment plan, not even to test environments since DevOps team was not aware of this project at all. Thus, QA cannot create any test suites and have to test everything manually which eats a lot of their time.

This whole project is a big hot mess and I’m considering leaving it all together especially since I’m working on two squads at the same time. I love the project, I love the idea, but management makes it unbearable, so I’m not even motivated to work on that.

Writing unit tests on a weekend and catching up on work that needs to be done because I m too busy on weekdays to have time to think about this...

The sad thing is test coverage is shit in the entire code base as boss just decided to start enforcing requirements now... And I have this huge migrating from legacy system project that needs to be merged. And we'll the legacy system is even shittier

So I have to write unit tests for shit code that was never written with testing in mind...

On the other hand I reworked some testing utilities to make it easier... For everyone... I want a huge bonus.... That I probably won't get...

Today I read a great article on mutation tests, how to use and why they are important. It looks like a great thing, but...
I have never wrote any unit test in any of my jobs. Nobody in my workplace does that. And now it seems like 100% test coverage is not enough (I remind you, that I have 0%), they all should mutate to check if the quality of unit tests is high.
It seems that I'm left behind. I played with tests in my free time, but it seems the more you write them, the better you get at it, so I should be writing them in my job, where I code most of my time. Not only that, of course, I would also want to ensure that what I'm working on is bug-free.
Still, it will be impossible to introduce unit tests to my project, because they are novelty to the whole team and our deadlines are tight. The other thing is, we are supposed to write minimum viable product, as it is a demo for a client, and every line of code matters. Some might say that we are delusional that after we finish demo we will make things the right way.
Did any one of you have a situation like this? How did you change your boss and team's mind?

My company never used unit tests. And i would love to educate but i do not know how to unit test properly. I always en up with: if i want to properly test all ins and outs of this class's + operator. I need to add checks for positive number, negative numbers, nan, infinites, nulls etc. Etc. It needs so many tests for something so stupidly simple, that i don't see a way to motivate people to use it.

Am i missing something? Is there a guideline for "ok coverage"? Is testing just that much work and is that why nobody cares until it is too late?

I have been reading a book about working with legacy code. But still i got no answers. Halp!

When your unit test gives coverage to your friend's code and it's a weekend bruh !! ❤️😎🤘🔥

In my company we are constricted to have 100% of f̶a̶k̶e̶ coverage with unit test.
Obviously the test suites are not performing and it takes more than 8 minutes to run 3335 tests.

I know that what I'm going to say is super mainstream but there is nothing comparable to the relief that comes from seeing all tests in green after you did a lot of small changes around the code on Friday.

My fellow developer was given a responsibility of writing unit test cases.
And instead of mocking the db calls he ended up making actual calls to db and adding realtime data to firestore everytime a test runs. Also he used mocha for the same. When i told him that we need to mock the db calls he said he will use sinon.js for the same and for code coverage his plans were to use istanbul.
I was like FUCKKKKKKK. , why the fk you aren't using jest. I mean whyyyyyyyy. WHAT THE FK

days ago i used to be very lazy about writing tests.. after forcing me doing it, I ended up being addicted to high line coverage... kind of satisfiying AF

I really hate how steep the learning curve is for testing. I've been writing the same test for a week for a 150 line directive, and it's driving me fucking nuts. Nothing makes sense. No one in the office to help me. Only 10% of engineers here write any tests. I don't know what to do. Overnight they made it a rule that if you want to move up to the next level for software engineers, 80% of your code needs to have unit test coverage. It's just bullshit.

What should I do, I have a central function that is not documentated and no test-cases are written for it. I have no clue what the method should really do, I know that it works in 99.9% of all cases otherwise we had much more bugs. Now there is one Unit-Test that reports an issue. I tracked it down to this method, no one touched the method nor the unit-test.
My logical thinking says that there is one statement missing, but it could also fuck up another part of the code... (This project has a bad testing coverage :'( )

What would you do?

- copy paste the method for this special case (I would hate me so much for breaking DRY)
- inheritance?! (Would make it more complex and then it would be still untested / undocumented)
- YOLO changing oO?! (hope for luck, just joking)

P.s it's an edge case unit test, the client / customer probably wouldn't realised it if it happens

Audience question to Uncle Bob: Which parts of the code do you unit test? What about code coverage?
Uncle Bob: Well (chuckling).. You test the parts of the code that you want to work.

I have actually two, but I'll write the other one in the week.

So we had classes about software engineering. The class was interesting but the teacher wasn't. Too soft, too slow, too low, too monochord (usual french), it was boring. So we ended up not listening to him. Kinda regret this.

We got a first exam, where we were in group to develop a Test Manager for Unit Test (yep.)
We had instructions, like the note would be multiplied by the percentage of coverage of code, etc.

The thing is, we really didn't get the point of the project. Now that I think of it, it seems obvious, but it wasn't back then as it was too new. In the four people of our group, one worked real hard on it, I tried to do my best, the others too.

But like I said, I didn't get back then the point of the topic, which is to apply design pattern, unit testing, etc. It was furstating af and we ended up with a 9/20.

I got the point of the topic only for the second exam, the most classic one, on a paper sheet with questions to answer. (We were allowed only one cheatsheet, I understood the topic while doing it. Sad, huh ?)