Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
Fuck today was weird.
Today I received almost half a million on my bank account. 😯
Someone changed the ancient cryptic billing system. My user account at work has id 32 in the database, and the dev referenced the size of the creditor id instead of the of the value of the ids itself, and they're u32 ints... So ALL the money moving through our platform was accidentally transferred to my associated bank account.
For all the unit tests we have, this bug tumbled right through.
And no one at finances thought a transfer that big, to a backend dev they know by name, was suspicious — with almost no money going to other creditors...
That worries me a bit. The fact that this shit can happen, even at high test coverage, just because someone mindlessly did a wrong autocomplete or something.
Of course I will send it back... after two weeks and a few hundred € of interest.12 -
Project handover:
"Mmh okay, so what about test coverage?"
Dev: "zero"
Team taking the project "why???"
Dev: "You don't need test if you write perfect code"
Silence in the room... Followed by awkward laugh.18 -
Just reached 100+!!
Anyhow. I started coding prettymuch 365 days ago. My mate decided to launch his company and figured it was a good idea to start it with good friends who knew fuck all at coding.
Fyi, the dude can code 15 hours straight everyday for about a year (no shit thats what i saw).
Since he taught me html css javascript(even if i still suck abit at js). He made me remake the whole bootstrap in react by adding this new lib styled-components and test everything(95% coverage :)).
He also taught me webpack and rollup. Json schma forms，http requests redux， redux logic， and all the routing shit...he obliged me to i plement RR4 on release and is now making me overlook the merge requests of my other collegue (yes he made me a git pro，almost).
And now i have to work long distance by studying java， spring， oauth2 and start working on our api.
O yeah，and i went from microsoft to full on linux!!!
To be honest i thought i was gonna die this year. (Also have a kid on the way :)).
Devrant has been like going to the psychologist :) everytime shit hit the fan i realized every one has the same problems :)
Thanks to the community i can also now even give out nerd jokes :)
(L)Devrant11 -
Testivus On Test Coverage
Early one morning, a programmer asked the great master:
“I am ready to write some unit tests. What code coverage should I aim for?”
The great master replied:
“Don’t worry about coverage, just write some good tests.”
The programmer smiled, bowed, and left.
...
Later that day, a second programmer asked the same question.
The great master pointed at a pot of boiling water and said:
“How many grains of rice should I put in that pot?”
The programmer, looking puzzled, replied:
“How can I possibly tell you? It depends on how many people you need to feed, how hungry they are, what other food you are serving, how much rice you have available, and so on.”
“Exactly,” said the great master.
The second programmer smiled, bowed, and left.
...
Toward the end of the day, a third programmer came and asked the same question about code coverage.
“Eighty percent and no less!” Replied the master in a stern voice, pounding his fist on the table.
The third programmer smiled, bowed, and left.
...
After this last reply, a young apprentice approached the great master:
“Great master, today I overheard you answer the same question about code coverage with three different answers. Why?”
The great master stood up from his chair:
“Come get some fresh tea with me and let’s talk about it.”
After they filled their cups with smoking hot green tea, the great master began to answer:
“The first programmer is new and just getting started with testing. Right now he has a lot of code and no tests. He has a long way to go; focusing on code coverage at this time would be depressing and quite useless. He’s better off just getting used to writing and running some tests. He can worry about coverage later.”
“The second programmer, on the other hand, is quite experience both at programming and testing. When I replied by asking her how many grains of rice I should put in a pot, I helped her realize that the amount of testing necessary depends on a number of factors, and she knows those factors better than I do – it’s her code after all. There is no single, simple, answer, and she’s smart enough to handle the truth and work with that.”
“I see,” said the young apprentice, “but if there is no single simple answer, then why did you answer the third programmer ‘Eighty percent and no less’?”
The great master laughed so hard and loud that his belly, evidence that he drank more than just green tea, flopped up and down.
“The third programmer wants only simple answers – even when there are no simple answers … and then does not follow them anyway.”
The young apprentice and the grizzled great master finished drinking their tea in contemplative silence.
Found on stack overflow https://stackoverflow.com/questions...8 -
To be a good developer, you must thrive in chaos, and have an insatiable desire to turn it into order.
All user input, both work tasks and actual application input, is pure fucking chaos.
The only way to turn that input into anything usable, is to interpret, structure and categorize it, to describe the rules for transformation as adequately as you can.
Sometimes companies create semi-helpful roles to assist you with this process. Often, these people are so unaware of the delicacy of the existing chaos, that any decision they make just ripples out in waves leaving nearly irreparable confusion and destruction in its path.
So applications themselves also slowly wear down into chaos under pressure of chaotic steak-holders which never seem to be able to choose between peppercorn or bernaise sauce for their steaks.
Features are added, data is migrated between formats, rules become unclear. Is ketchup even fucking valid, as a steak sauce?
The only way to preserve an application long term, is refactoring chaos into order.
But... the ocean of chaos will never end.
You must learn to swim in it.
All you can hope to do is create little pools of clarity where new creative ideas can freely spawn.
Ideas which will no doubt end up polluting their own environment, but that's a problem for tomorrow.
So you must learn to deal with the infinite stream of perplexed reactions from those who can't attach screenshots to issue reports.
You must deflect dragging conversations from those who never quite manage to translate gut feeling into rational sentences.
You must learn to deal with the fact that in reality there are no true microservice backends. There are no clean React frontends. There are no normalized databases. Full test coverage, well-executed retrospectives, finished sprints -- they are all as real as spherical cows in a vacuum.
There is no such thing as clean code.
There is only "relatively cleaner code", and even then there are arguments as to why it would be "subjectively relatively cleaner code".
Every repository, every product, every team and every company is an amalgamation of half-implemented ideals, well-intended tug of war games, and brilliantly shattered dreams.
You will encounter fragmented shards of perfect APIs, miles of tangled barbed documentation, beheaded validator classes, bloody mangled corpses of analytical dashboards, crumbled concrete databases.
You must be able to breathe in those thick toxic clouds of rotting technical and procedural debt, look at your reflection in the locker room mirror while you struggle yourself into a hazmat suit, and think:
"Fuck yes, I was born for this job".26 -
Every day.
I am a PHP developer.
Yeah, "another PHP is awful" rant... no, not really.
It's just unsuitable for some ambitious projects, just like Ruby and Python are.
First of all, DO NOT EVER use Laravel for large enterprise applications. The same goes for RoR, Django, and other ActiveRecord MVCs.
They are all neat frameworks for writing a todo app, as a better-than-wordpress flexible blogging solution, even as a custom webshop.
Beyond 50k daily users, Active Record becomes hell due to it's lazy fat querying habits. At more than a million users... *depressed sigh*.
PHP is also completely unsuitable for projects beyond 5M lines of code in my opinion. At more than 25M lines... *another depressed sigh*.
You can let your devs read Clean Code and books about architecture patterns, you can teach them about SOLID & DRY, you can write thousands of tests... it doesn't matter.
PHP is scaffolding, it's made of bamboo and rope. It's not brick or concrete. You can build quickly, but it only scales up to a certain point before it breaks in multiple places.
Eventually you run into patterns where even 100% test coverage still doesn't guarantee shit, because the real-life edge cases are just too complex and numerous.
When you're working on a multi-party invoicing system with adapters for various tax codes, or an availability/planning system working across timezones, or systems which implement geographical routefinding coupled to traffic, event & weather prediction...
PHP, Python, Ruby, etc are just missing types.
Every day I run into bugs which could have been prevented if you could use ADTs in a generic way in PHP. PHP7 has pretty good typehints, and they prevent a lot of messy behavior, but they aren't composable. There is no way to tell PHP "this method accepts a Collection of Users", or "this methods returns maybe either an Apple or a Pear, and I want to force the caller to handle both Apple/Pear and null".
Well, you could do that, but it requires a lot of custom classes and trickery, and you have to rewrite the same logic if you want to typehint a "Collection of Departments" instead of "Collection of Users" -- i.e., it's not composable.
Probably the biggest issue is that languages with a (mostly) structural type system (Haskell, Rust, even C#/JVM languages to some degree, etc) are much slower to develop in for the "startup" era of a project, so you grab a weak, quick prototyping language to get started.
Then, when you reach a more grown up phase, you wish you had a better type system at your disposal...28 -
Newspaper: This CEO is one of the top entrepreneurs in the country, a true tech visionary shaping the future.
--- 3 months previous ---
Lead dev: O2 have said they are will pre-install the app on all their Androids but they need documentation from us.
CEO: documentation? on what?
Lead dev: Our unit test coverage, bugs found / fixed, security scan results, performance assessment, if and where its storing any data etc.
CEO: Ah were not doing any of that crap, bloody unit tests, its not necessary, tell them no.
lead dev: ..... eh ok
O2: *approved*
... true visionary, well done to everyone involved.3 -
DevOps is like development, except there is zero test coverage, everything is a race condition, and there are a million variables declared as global. 😡8
-
Passed the online test.
Passed the technical interview.
Need to pass the final interview.
I'm applying to this company as a JS developer (backend). Their engineers are amazing and the fucking have 99.94% coverage on their test suiteeee; that gave me a code-boner.
If I get this job I'll finally say good bye to fucking PHPShit and Zend Framefuck and all this hacked bootstrap and 15k LoC "core.css/js"
I CAN DO IT10 -
Just did my first pull request for an open source project ever. And it actually increased test coverage for the whole project 😂2
-
It's enough. I have to quit my job.
December last year I've started working for a company doing finance. Since it was a serious-sounding field, I tought I'd be better off than with my previous employer. Which was kinda the family-agency where you can do pretty much anything you want without any real concequences, nor structures. I liked it, but the professionalism was missing.
Turns out, they do operate more professionally, but the intern mood and commitment is awful. They all pretty much bash on eachother. And the root cause of this and why it will stay like this is simply the Project Lead.
The plan was that I was positioned as glue between Design/UX and Backend to then make the best Frontend for the situation. Since that is somewhat new and has the most potential to get better. Beside, this is what the customer sees everyday.
After just two months, an retrospective and a hell lot of communication with co-workers, I've decided that there is no other way other than to leave.
I had a weekly productivity of 60h+ (work and private, sometimes up to 80h). I had no problems with that, I was happy to work, but since working in this company, my weekly productivity dropped to 25~30h. Not only can I not work for a whole proper work-week, this time still includes private projects. So in hindsight, I efficiently work less than 20h for my actual job.
The Product lead just wants feature on top of feature, our customers don't want to pay concepts, but also won't give us exact specifications on what they want.
Refactoring is forbidden since we get to many issues/bugs on a daily basis so we won't get time.
An re-design is forbidden because that would mean that all Screens have to be re-designed.
The product should be responsive, but none of the components feel finished on Desktop - don't talk about mobile, it doesn't exist.
The Designer next to me has to make 200+ Screens for Desktop and Mobile JUST so we can change the primary colors for an potential new customer, nothing more. Remember that we don't have responsiveness? Guess what, that should be purposely included on the Designs (and it looks awful).
I may hate PHP, but I can still work with it. But not here, this is worse then any ecommerce. I have to fix legacy backend code that has no test coverage. But I haven't touched php for 4 years, letalone wrote sql (I hate it). There should be no reason whatsoever to let me do this kind of work, as FRONTEND ARCHITECT.
After an (short) analysis of the Frontend, I conclude that it is required to be rewritten to 90%. There have been no performance checks for the Client/UI, therefor not only the components behave badly, but the whole system is slow as FUCK! Back in my days I wrote jQuery, but even that shit was faster than the architecuture of this React Multi-instance app. Nothing is shared, most of the AppState correlate to other instances.
The Backend. Oh boy. Not only do we use an shitty outated open-source project with tons of XSS possibillities as base, no we clone that shit and COPY OUR SOURCES ON TOP. But since these people also don't want to write SQL, they tought using Symfony as base on top of the base would be an good idea.
Generally speaking (and done right), this is true. but not then there will be no time and not properly checked. As I said I'm working on Legacy code. And the more I look into it, the more Bugs I find. Nothing too bad, but it's still a bad sign why the webservices are buggy in general. And therefor, the buggyness has to travel into the frontend.
And now the last goodies:
- Composer itself is commited to the repo (the fucking .phar!)
- Deployments never work and every release is done manually
- We commit an "_TRASH" folder
- There is an secret ongoing refactoring in the root of the Project called "_REFACTORING" (right, no branches)
- I cannot test locally, nor have just the Frontend locally connected to the Staging webservices
- I am required to upload my sources I write to an in-house server that get's shared with the other coworkers
- This is the only Linux server here and all of the permissions are fucked up
- We don't have versions, nor builds, we use the current Date as build number, but nothing simple to read, nonono. It's has to be an german Date, with only numbers and has always to end with "00"
- They take security "super serious" but disable the abillity to unlock your device with your fingerprint sensor ON PURPOSE
My brain hurts, maybe I'll post more on this shit fucking cuntfuck company. Sorry to be rude, but this triggers me sooo much!2 -
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.8 -
Casual workday be like:
Project manager: It is important we deliver these features.
Me & Coworker: Sounds reasonable, here is how long we need, roughly.
Mgr: Well, the deadline is already set and the contract is signed and written.
M&C: Ummm...
Mgr: Also, while we are hosting the application, we are not paid for operational cost, so make sure to optimise the crap out of it immediatly. Preferably while developing the features.
(A wild architect appears): Also everything has to be built on cans and kubernuts, with rectangular ui and bootstyling and with these internally developed backend frameworks NOBODY tests. Coroporate policy you know.
(A wilder division CEO appears on meeting): Also we are rolling out code KPI's across the organisation. Everyone is expected to Focus on documentation, test coverage and there is now mandatory SonarQube scanning of repos. ZERO DEFECTS PEOPLE
M&C: ...
(Wildest Salesteam appears): By the way we sold the application to these other customers, they love feature XYZ and must have it.
M&C: It does not have feature XYZ
Mgr: It will have feature XYZ
M&C: Allright so with all the extra funding from the sales, we need to hire atleast one Machine learning guy, an extra frontend specialist a developer and maybe funnel some of the funding into slacking the operational budget in the start.
Animated Suit *Railing a line of coke from his gold plated ihpone 15*: What funding? Get to work. Also your havent been super sharp with your time registration.
2 -
"As a team, we have the shared responsibility to ___".
(replace with ALL of the following: resolve bugs, do junior's code reviews, clean up dead code, keep the kitchen clean, improve test coverage, write documentation, order coffee beans, etc)
NO. JUST FUCKING STOP RIGHT THERE. Shared responsibilities do not exist. A single person is responsible, and can optionally delegate tasks.
EITHER I DO IT AND I'LL BE FUCKING AWESOME AT IT, OR SOMEONE ELSE DOES — BUT I'LL SLAP SLACKERS IN THE GENITALS WITH MY KEYBOARD.
Fucking startup hipsters with their community driven attitude, this way no shit gets done, ever.7 -
On the first day of Christmas, the bossman gave to me: The fact that my new computer purchase order needs to be OKed by the CEO and I need to continue working on a 2014 Mac Mini (i5-4260U, 8 Gig RAM, GPU shot by an ESD on the case long ago) for the next year.
On the second day of Christmas, my family gave to me... a good reason to get shitfaced
On the third day of Christmas, getting shitfaced gave to me: A hangover and some urgent plastic welding job that had to be done with a soldering iron. FML, I've had a headache before breathing in pure hydro-cyano-whatthefuckyougetwhenyoumeltplastics
On the fourth day of Christmas, my team gave to me: A legacy, age-old Rails 2 project that was written by an intern and never reviewed, went to prod in 2014 and can't be changed anymore, but needs to be changed after the fact that it has zero test coverage and needs 100 % now to prevent issues and costly manual testing.
On the fifth day of Christmas, devrant gave to me: The Idea that making fun of Christmas songs to get over the sheer amount of dicks that working over the twelve days of Christmas sucks.
To be continued...2 -
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.3 -
After running tests, code review, coverage test ... And your application crashes in the middle of a demo in front of your PM and your coworkers.
Coworkers : "When you try your best but you don't succeed ..." (Coldplay song)
PM : DAMN SON! WHERE'D FIND THIS ?4 -
We have a huge codebase, built during the last 10 years, with a lot of problems caused by legacy dependencies. We are trying to modernize this gradually but it is very challenging because we have a lot of features to maintain and test coverage is low.
Today, a guy hired three days ago just proposed to rebuilt everything from scratch stating that he did the same thing in his personal project, so it wouldn't take too much to develop what we need.
Manager gently invited him having a quick call. I would pay to listen that conversation.8 -
A) Create something that works, is fast, minimum bugs, have edge cases covered, nice testes, clean code. Cool, you did your job. END.
B) Create something shitty with bugs, performance issues, non or poor test coverage, mess code, etc. Cool, you did you job. But...
Next week you reduced bugs by 50%. Wow, you're rockstar.
Another week you improved performance by 15%. Again, you're the hero.
2 weeks later, you reached 85% test coverage. Management is so happy that almost got orgasm.
"A" took 3 months, "B" took 3 months plus few months of fixes. The only time where B was winning was first 4 weeks, where A was carefully building it's architecture and quality.
Yet B is seemed more successful.
This industry is F****d Up beyond my understanding.7 -
The 2018 bucket list!
I sort of swear to be a good coder, to take honour and dignity in all the lines I write, I will not take shortcuts, I will obtain a +80% test coverage across my projects, write clean and accurate documentation, and ultimately I will write less bugs!
Yea..., probably not but worth a try anyway!!1 -
Me: We really need to improve our unit test coverage.
Team/Boss: <sarcasm> Haha yeah.
Production Bug: I'm doing something nasty to a client, because a dev broke something but no test coverage.
Boss: How could we have prevented this?!1 -
Soooo it's Monday........ 🤯
@C0D4 started the day fixing current projects defects (4 tickets smashed before coffee 💪)
Then after coffee, run a test coverage report and see a significant decline over the past few months, so spends a couple hours adding more tests to get some areas filled in - meh, nothing like 50+ lines per test... to test a if() statement but whatever - complex scenarios will be complex to get too, but no my tests break and I'm missing data I didn't know about🤦♂️
So let's comment all that out, and go to lunch ... mmmm lunch.
Get back, start working on those again, and then get handed a new issue, so comment that all back out again, ( ok I know what you're thinking, but I'm working in an environment that does not use git for deployments - don't ask, real pain in the ass I haven't had time to invest into yet - but as code versioning only) anywho, starts to workout this new issue but don't figure it out, enter a 30 minute meeting.................. yea that was 2 hours later but was a very practical whiteboard session only to work out I have something like 16-20 weeks of work over 4-5 projects to get out in like 6 weeks... hahahahahahaha fml..... oh and that's excluding another project which had a 6 weeks of work in the pipeline to get to somehow.... I'm not seeing this one happening, and probably conflicting projects needed on top of that down the track... but we'll leave those out for now!
Whoot is fucking home time!!!
🤷♂️I'm starting to think I'm like a team of 5-10 devs right now, maybe I should start asking for 5-10x more 😏
#letsBringOnTuesday!!!!4 -
I've been staffed on a old ongoing project, first day.
0. Compatibility has to be guaranteed down till IE9... ppf.
1. Front end made in XHTML+JS(jQuery)... bah, ok.
2. XHTML+JS is actually generated by PHP5.4, not a line is actually statically served... beh, funny, ok.
3. PHP files are the output of an XSLT transform of a bunch of XMLs... meh, seriously? Oooook.
4. XMLs are the product of the serialisation of a truck of stateful JavaEE6 DTOs populated magically (undocumented) with data coming from a SQL DB... WTF mode!!!
5. Session logics lives within PHP-land at point 2, front end makes ajax calls here that propagates to another WS out of our control that triggers -somehow- (undocumented) our Java backend at point 4 to generate new XMLs and then reach front end again. Kill me now.
Boss: look... it's too slow for the client, it's too heavy on our servers: fix it. Ah, and we sold 85% test coverage by October. You're the man for the job. (I'm a Node.js fullstacker and right now there's not even a testing scaffold, ofc).
Me: prod is on Linux or Windows?
Boss: RHEL7.
Me: rm -rf / as root. Done.
Boss: I know I know...
Me: ...
I think time has come...6 -
My company’s upper leadership is sooo focused on the NUMBER of defects that are open on our project and only the number. We give each defect a priority of P0, P1, or P2. You would think this would help prioritize and strategize our plan to fix them. But nope. Every week we have some arbitrary “goal” to hit. A number purely made up by clueless leadership as to what makes a “quality” product.
On Friday’s, managers start harassing devs to merge their fixes and for QA to close out defects. So effectively rushing to hit that arbitrary number or else we’ll have to work Saturday.
Meanwhile they want more test automation coverage to reduce the incoming defect rate. But when the fuck do we have time to develop said tests when all you want is the defect closed to bring down your precious little number?!
They’d rather us close 25 P2 defects to bring the number down rather than 10 P0 or P1 defects. These leaders are so incompetent it kills me! Without any back story, they’re ultimately the reason we’re in this position in the first place! Argghhh!2 -
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 🤦🏻♂️12 -
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.... -
After a long time I finally reached this milestone of 100% code coverage. I often asked myself why I had to test every function, no matter how small. But this log output of 100% was worth it.
4 -
"We need more test coverage!"
it("should test that function") {
subject.function();
expect(true).toBe(true);
}
Coverage goes up 30%
"Awesome! Now we're TDD!" -
My colleague: I don't want to increase test coverage, we still have bugs.
Dude we have bugs because we don't have tests...7 -
Group assignment in a software engineering class. Got that notorious lazy kid in my group of four who failed the class in the last term. I was perfectly aware of his reputation, but accepted him in the group nonetheless, because he already knows what needs to be done in the class.
He started to work on his assignment: mostly boilerplate code that didn't even build. He didn't even bother to fix it. I had a lot of time over the Easter weekend, so I decided to just code as much for the assignment as possible for the mid-term submission. I replaced his broken boilerplate stuff with a working solution. I told the others in the group chat about it. Code works and builds, test coverage is high. Everything is fine.
The lazy kid replied to the group chat, that if I'd wanted to code and document(!) everything on my own, I should have told him in the first place. Also got that "fuck off" emoji in the message. So I restored his broken boilerplate stuff using git, even fixed the build errors and told him to explain to me what he tried to achieve, and that I'd be happy to include his code as soon as it worked. Didn't hear anything since. Commits neither.
I guess he was just looking for an excuse for not doing additional work in the project.1 -
When I got in this job:
No test, 0% coverage
No teamwork
No documentation (front and backend)
Senior doesnt want to talk
1year later:
We have test prolly 10% coverage
Still no team work
No documentation
Senior doesn’t want to talk
Ps: tried doing documentation but I cant unless my senior will help me because I dont know the ins and outs of the codebase.
I say crap.12 -
OK people, I don't need a novel written for every line of code, but PLEASE STOP trying to tell me that "yOuR coDe sHouLd bE sELf dOcUmeNtiNg aNd cOmMenTs mEaN iT's aUtoMaTiCaLLy bAd". That's a bunch of BS. I can't begin to tell you how many times I've saved my own butt by dropping a "this call can't be awaited; causes the library's internal API to throw an error" comment in my C#, or a "can't use double quotes here; doesn't work right for some reason" line in my JavaScript. Sometimes there are very good but un-obvious reasons why something was done a certain way, even though it looks like it could be done better. And don't try to tell me "the tests will catch it". Let's be realistic here, nobody has 100% test coverage on any project that's much more than "Hello World". And even if the tests DID catch it, why waste the time when you could just write a comment?
P.S.: This is not directed at anyone on here specifically. It's directed at all the devs I've met IRL and the comments I've seen on SO, who think that comments must be bad.15 -
!rant
Designed and written > 1.3k lines of code this week and 98% test coverage..
CI and CD set up and working..
Was a Long week and very exhausting but I feel really good now, happy to start the weekend with whiskey and beer.
This is gonna be one of my most productive sprints so far..
Hope you all had a successful week as well.
Happy Friday 🍻
And please don’t start with any „that’s nothing, I’ve written 5k lines ones“ comments.. It‘s professional, stable, optimized code and code I can actually be proud of.6 -
I really want to stress that we should add the ticket for adding the missing test cases in *this* sprint and not postpone it any further.
-- "Isn't there something more important to be added instead?"
There. ALWAYS. Is. Something. MORE. Important. The real problem was that we implement the test cases in the past to begin violating our definition of done. We have to fix and one point and we have to own that decision as nobody else will care about passing tests and test coverage. It's our job to care for that.
Yes, we can instead focus on all the other high-priorities task that should have been done yesterday, yet that won't change the fact that large part our codebase will remain an untested messy blackbox just asking for weird bugs and wild goosechases in the future.
Don't hide behind "high priority tasks". A job is done when it is fucking done and tests are part of that. Hurrying from one important task to the next will just mean we'll never do it. There is no better time than right now.
If code coverage got left behind in the past, then we'll have to suck it up in order to fix it as soon as possible, otherwise we'll just suck forever.1 -
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.4
-
It’s actually been quite a fun day, after some ranting on one of our slack communities flutter channel, myself and my team realized we were in a really good place to give back.
We have been working on a large scale flutter application for about a year, phase 1 is about done and we at 11k LOC.
We have been doing a big push for testing over the last 2 months and are at about 50% coverage. The thing we realized is that is the 1 place flutter has fallen short with documentation.
Very little about what we learned for testing our code came out of a google search, or it came out of cobbling bits together from numerous searches and sources.
So we decided we are going to plan and host a virtual meetup to discuss what we have learned and hopefully teach a few people some useful things and hopefully also learn a few new things too.
In addition, and as it has a longer shelf life, we going to setup a medium publication for the company and start a series to cover small specific topics, specific use cases or scenarios that we had trouble with and solved.
Today I had my first thing to type out, had worked out how to test that a function that was passed into a widget was called. So the parent passes the child and onTap function but you are testing the child not the parent as the child is reusable...
Anyway, so with that idea I got hold of marketing for some assets, setup the publication and proceeded to type out 3 articles today, all nice short ones under 2 min reading time.
It really is nice to give back, it’s not like I am Remi smart and can go and write BLoC, but I am smart enough to figure shit out and type it up so that the next guy hopefully benefits from my brain bashing.6 -
Worst architecture I've seen?
The worst (working here) follow the academic pattern of trying to be perfect when the only measure of 'perfect' should be the user saying "Thank you" or one that no one knows about (the 'it just works' architectural pattern).
A senior developer with a masters degree in software engineering developed a class/object architecture for representing an Invoice in our system. Took almost 3 months to come up with ..
- Contained over 50 interfaces (IInvoice, IOrder, IProduct, etc. mostly just data bags)
- Abstract classes that implemented the interfaces
- Concrete classes that injected behavior via the abstract classes (constructors, Copy methods, converter functions, etc)
- Various data access (SQL server/WCF services) factories
During code reviews I kept saying this design was too complex and too brittle for the changes everyone knew were coming. The web team that would ultimately be using the framework had, at best, vague requirements. Because he had a masters degree, he knew best.
He was proud of nearly perfect academic design (almost 100% test code coverage, very nice class diagrams, lines and boxes, auto-generated documentation, etc), until the DBAs changed table relationships (1:1 turned into 1:M and M:M), field names, etc, and users changed business requirements (ex. concept of an invoice fee changed the total amount due calculation, which broke nearly everything).
That change caused a ripple affect that resulted in a major delay in the web site feature release.
By the time the developer fixed all the issues, the web team wrote their framework and hit the database directly (Dapper+simple DTOs) and his library was never used.1 -
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?7 -
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!1 -
After building some automated regression tests to verify parts of the company website were working, it was discovered that a test case was missing.
Instead of a constructive meeting about fixing the issue and adding a test, I was reamed and my manager was reamed that we "missed this case".
Nevermind that the automation caught several issues before release in nearly every other aspect of coverage.
Nevermind that the missing test case was a useless feature added after the automation was completed.
Nevermind that automation was meant to be the last stop in the gate, not the first...
I was so livid after that meeting I nearly resigned on the spot. My manager was so livid over being told to write me up he was ready to resign. -
Assertequals("Fail","Fail") in the catch block.
Things developers do to bloat their test coverage at my organisation,
I am #stuckWithIdiots
Management sees green1 -
rant?
When you want to write the unit test that demonstrates a subtle bug, but before recreating the same preconditions you end up writing 15 other tests, testing a lot of other stuff too, that in turn show other bugs, and skyrocketing the coverage (that was sitting at 0% actually).
Like I wanted to repair a hole in my umbrella to not get wet, and built a house instead. -
Let's face it: I am and will always be a tinkerer. Yes, I know my ways around, I can sneak into legacy code bases easily and throw new stuff in there, I've seen software stacks. But scarcely sound design, really modular. Even from the cleverer, experienced ones. They can master more complexity, so they can handle more spaghetti. Some essay from the 80's had this grand idea to organically 'grow' software. That's how it looks like most of the times: cancerous, parasitic super fungi (armillaria). Yeah, we all know have to fight bit-rot and entropy, but it was all lost before already. We'll never get rid of legacy protocols, legacy code.
And even when we go green field, start a fresh. Yeah, take a great design, make everything new, after some months of throwing features and outer constraints at the thing, it's the same old mud again.
But we can still dream on: some day I will design great APIs, I will have great test coverage, documentation, UML design, autometed tests, fuzzing, memchecking, I'll work professionally, clean coder style.
Pfft forget it. Maybe change for consulting, because we'll continue to dream of the 'clean' code, so you can sell the next 'recipe', development method. It's like diets. As effective. For the one selling.2 -
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.2
-
Fixed a high priority bug today just prior to release. There was 100% test coverage. The tests pass both before and after the change. The product behavior is correct now where it wasn't before. Just one more reminder that test coverage does not equate to either quality or correctness. Tests are alarms (at best), and quality of tests are no better an any chunk of code. All tests have costs, but not all have value. All reasons why I am skeptical of the value of code coverage, TDD, or anything that posits that "all tests are good".6
-
So, after having my mental breakdown with the 500k LoC Zend Frameshit PHFuck 5.5 with 0 test project, for a whole year; and after moving to a better job, I now inherited a React/Node/GraphQL project with a shitty architecture. It's so shit technical debt can almost be payed with actual cash... or flesh, ass-for-arch.
However, line test coverage is over 90%, so I guess it is an improvement.1 -
So I've a little freelance project, is basically a blog. I've decided to use microservices with angular in the front end and python in the backend.
I've been about 2 weeks copy pasting code in my api because all the modules are pretty simple CRUDs that do the same thing, there is not heavy business logic or anything, just database handling.
I was really tired of copy pasting modules and his test, only changing function names and parameters, today I've this "epifany" about the inheritance and thinked about using it in my service, creating a base class and making all the other classes children of him.
Before the change my project has 220 tests (100% coverage) now I have only 40 tests (the same 100% coverage)
So, the lesson is: don't start throwing code like an idiot and start your project with some good planning1 -
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...2 -
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.5 -
[
'!rant Today I traded xdebug for test coverage with pcov, my god this is so much quicker now!',
'My mysql development container would not start because the password was too long, what even... Not a clear error or anything, it just wouldnt let anything else connect',
'!rant This week I have suddenly become motivated to functionally test the shit out of my projects, it feels SOOO good',
]2 -
I'm in a situation at work where management and even the team I'm on, does not want to create a test suite, because:
1. It takes time to get decent code coverage. Time that could be spend doing new features
2. My team doesn't like to test.
We're now in a situation where we break something every single fucking time we relase and the manager just ignore that it's now a common occurrence. It it literally just a matter of time before the entire fucking backend will shit itself over poorly maintenanced code (who has time to do refactoring anyway) and poorly tested flow.
It annoys me greatly that a developer with many years of experience fails to see and understand that just doing test by hand, screws us over so badly.
As a junior dev, i would like to know, how are your team dealing with testing?
Because we're clearly not...9 -
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!7 -
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?7 -
God dammit, I hate my bloody coworker sometimes. He's doing a huge refactor, and committing... which is fine, but he's clearly NEVER run the fucking test suite. I didn't write that much coverage so you could commit something that breaks the build and then fuck off to lunch.
Not only has he not run the test suite, I don't think he's run his changes AT ALL. The bloody modules don't even import the way he's written it now.2 -
1. Test coverage not consisting of flaky brittle tests
2. Native type checking in JS (v8 engine)
3. Less meetings.7 -
Here's my checklist:
- education opportunities? Conferences etc.
- blogging?
- open source contribution?
- test coverage?
- CI/CD?
- always meet with the team -
When you don't know how to write test:
either you unit test the fuck out of system (couple test test to code) or you don't write anny
-
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
-
TLDR: Wrote a custom class for writing apibtest cases for a project with zero code test coverage.
We have a project with zero test coverage. Recently, i was tasked with writing api test cases for said project, it might have taken me months to write tests for all endpoint, plus the main issue was that each endpoint needed to tested for all available user roles and permissions.
I tried the main stream approach of writing api tests, but ended up running into a lot of issues directly linked to our projects roles/permissions architecture (cherry on top some endpoint are apikey specific). Don't get me wrong in my opinion this is by far one of the best user roles architecture out there, but writing test cases keeping it in mind is pain in ***.
After trying out different testing methods and frameworks, i decided to write my own class by extending django test framework (which uses unitest)
- It has generator and validators for request and response.
- Supports testing for user roles and permissions.
- We won't have to make any changes to code after user role or permissions changes
- I just have to copy and past request and responses from postman api collection.😂
1 -
Feeling a strong temptation to go in and just do some random refactoring on my work project. It has massive view controllers and 30% test coverage. I dunno about anyone else but in my book thats not good enough to release to paying customers.
-
Me: Writes tests while fixing bug
Supervisor: "I'd suggest fixing other bugs and then picking up test cases"
Well the reasons we have so many bugs is that you let our off-shore devs just write code with ZERO code coverage!! -
Got a colleague here who is very competitive. If I say that "I've got 90% test coverage", he'd say he's got 95. If I solve something and share it to him, he'd go to the boss and tell that he's the one who solved it. 😳2
-
when you create > 25-30 java classes because you have to fix the code from someone else and it has to be done to get tested.
test coverage > 90% -
I've taken to only allowing PRs on my code if test coverage only deviates negatively within 1%
You can almost hear the tumbleweed.
But that hasn't been merged in yet -
So I'm working on this codebase that has about 50k lines of code and I built a feature in it today. Spent 3hours on the feature + writing tests. Then I raised a pull request and that bastard codeclimate calculated the test coverage had dropped by 0.3%.
For 6hours now I'm still looking for a way to increase the test coverage by 0.2%. FML4 -
Jonathan Burnhams
Started my career under him, learnt a lot from him....writing neat and simple code, with always 100% test coverage.
Very strict and straight forward. -
That kind of devs that creat unit test for a method never used in code instead of deleting it. #CoverageGoals
-
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.4
-
What do you think about my sibling observation today (he/she is not in software):
- if you want make money in any company, deal with all the shit: incompetent co-workers, shitty management, unreasonable deadlines, misinterpreted Agile, no test coverage, etc.
- if you want to grow and develop yourself: join some easy startup or make your own app/project3 -
This article about the types of legacy code bases you will have to deal with just made my day!
Not only do I have every one it describes but somehow it even made me laugh at thought of each of the std riddled petri dishes of code that I reluctantly maintain... My "Happy Place" is a folder dedicated to reliquary projects I like to look at when I feel sad to lift my spirits and restore hope that one day things will be better.
Do you have any definitions to add or know where to find more? I'm hooked.
Link: https://medium.com/@dylanbeattie/...
Excerpt:
The Reliquary
The reliquary is that one repository full of really good ideas. Clean code. Brilliant algorithms. The OpenID implementation that you optimised until it shone. Classes so beautifully designed and perfectly documented that they’d make a senior architect weep.
You remember the big rewrite? The project that was going to fix everything, only you never worked out how to actually launch the thing, or get any revenue from it? The reliquary is where you’ve preserved it, pickled in revision control like a fabulous museum specimen. A treasury of good code and good ideas; maybe even an entire codebase that was “a couple of weeks” away from shipping before somebody finally looked at the number of critical features the team had somehow forgotten to include and discovered — to everybody’s surprise — that validated XHTML, normalised data models and 95% test coverage are not actually features any of your end users cared about.
Like Buran or the Spruce Goose, the surviving artefacts stand as a testament to the quality of your engineering… and a poignant reminder of just how much fun engineers can have building high-quality stuff that nobody actually wants to use. -
Context: I am leaving my company to work at a data science lab in another one.
My senior dev (with PO hat): we need to gather data from prod to check test coverage. You will like it as you will be data scientist hehehe (actually not funny). You will have to analyze the features, and find relations between them to be able to compare with the existing tests
Me: oh cool, we can use ML to do that!
Him: Nope, we need to di it in the next 3 weeks so we need to do it manually.
Me:... I have quit for something.... -
Upgrading my tech skills.. Once again I feel my personal my personal dev environment and told are much more up-to-date than what I use at work.... Though the book Kim reading is on TDD and was written 3 years ago.
Maybe I should read another on in cloud services and ML... but don't have any motivation for these topics.
I need TDD for work because now we're emphasizing unit test coverage...
I usually only use manual functional tests to verify the final outputs as either the testing framework is broken (JS) or I don't have time to relearn the frameworks for the particular language...
Anyway got off topic... So questions after:
1. Do you ever feel your technologically always more ahead than what you do at work and essentially you bring skills to the job but you don't learn much out of it?
2. How do you test? I actually got into a bit of a argument/discussion with my colleagues about how to implement unit tests. Apparently there are 2 ways to test? Black box vs WhiteBox. She said she tests only Public methods using mock inputs, dependencies. She read online and seems there is an opinion that should only test public functions and if you can't then your app is designed incorrectly, not separated enough.
For me I test the private functions individually (WhiteBox/Java reflection) because the public one is like generateReport and as a whole is like a Pachinko machine, too many unique paths that would need a test case for.
So thoughts? Yes sorry for turning it into a remake I guess...25 -
I just want to test my PHP code using phpunit on GitLab, what am I doing wrong?
image: php:latest
before_script:
# Install & enable Xdebug for code coverage reports
- pecl install xdebug
- docker-php-ext-enable xdebug
# Run our tests
# If Xdebug was installed you can generate a coverage report and see code coverage metrics.
test:
script:
- phpunit Test.php4 -
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 -
Me: By mandating code coverage pct. (very high ones) and integration test coverage pct. you are building an ever growing Rube Goldberg machine that you will end up spending most of your time fixing rather than working on the actual product.
Them: (Staring and whispering in the background). Wow, you must be stupid. This is how you created quality software.
...time passes and now most time is sucked into figuring out why all branches have failing integration tests all the time.
Me: I told you so. I've seen it multiple times. How about doing it differently?
Them: (staring and whispering in background). You are stupid. This is exactly how quality software is built. We know what we are doing. You must like waterfall.4 -
Ah, strong motivation: get to 80% (or so) test coverage before my Goland trial expires today or tomorrow.
-
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 ?) -
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.
Top Tags
Weekly Rant
View
That's true