Let's clarify:
* Github is not Git
* Android is not Java
* Unit test is not TDD
* Java is not OOP
* Docker is not Devops
* Jenkins is not CI
* Agile is not institutionalised total chaos
* Developer is not Printer Support

Do you follow test driven development?

TDD in construction 🚧

Modern development methodologies:

SDD - sales driven development.
TDD - torture driven development.
BDD - bug driven development.
CPDD - copy&paste driven development.

I was writing tests at work and rather enjoying myself.

Boss insisted we all go home early because "holiday halfsies," so I semi-unhappily pack up and go home. At home, I write tests for a personal project instead.

Dev life.

CTO: "You must write good tests with high coverage, ideally use TDD. We need confidence in our releases."
Also CTO: *Secretly commits code changes directly to master at 3am, breaks tests, skips CI, publishes, tells no-one*

I'm drunk and I'll probably regret this, but here's a drunken rank of things I've learned as an engineer for the past 10 years.

The best way I've advanced my career is by changing companies.

Technology stacks don't really matter because there are like 15 basic patterns of software engineering in my field that apply. I work in data so it's not going to be the same as webdev or embedded. But all fields have about 10-20 core principles and the tech stack is just trying to make those things easier, so don't fret overit.

There's a reason why people recommend job hunting. If I'm unsatisfied at a job, it's probably time to move on.

I've made some good, lifelong friends at companies I've worked with. I don't need to make that a requirement of every place I work. I've been perfectly happy working at places where I didn't form friendships with my coworkers and I've been unhappy at places where I made some great friends.

I've learned to be honest with my manager. Not too honest, but honest enough where I can be authentic at work. What's the worse that can happen? He fire me? I'll just pick up a new job in 2 weeks.

If I'm awaken at 2am from being on-call for more than once per quarter, then something is seriously wrong and I will either fix it or quit.

pour another glass

Qualities of a good manager share a lot of qualities of a good engineer.

When I first started, I was enamored with technology and programming and computer science. I'm over it.

Good code is code that can be understood by a junior engineer. Great code can be understood by a first year CS freshman. The best code is no code at all.

The most underrated skill to learn as an engineer is how to document. Fuck, someone please teach me how to write good documentation. Seriously, if there's any recommendations, I'd seriously pay for a course (like probably a lot of money, maybe 1k for a course if it guaranteed that I could write good docs.)

Related to above, writing good proposals for changes is a great skill.

Almost every holy war out there (vim vs emacs, mac vs linux, whatever) doesn't matter... except one. See below.

The older I get, the more I appreciate dynamic languages. Fuck, I said it. Fight me.

If I ever find myself thinking I'm the smartest person in the room, it's time to leave.

I don't know why full stack webdevs are paid so poorly. No really, they should be paid like half a mil a year just base salary. Fuck they have to understand both front end AND back end AND how different browsers work AND networking AND databases AND caching AND differences between web and mobile AND omg what the fuck there's another framework out there that companies want to use? Seriously, why are webdevs paid so little.

We should hire more interns, they're awesome. Those energetic little fucks with their ideas. Even better when they can question or criticize something. I love interns.

sip

Don't meet your heroes. I paid 5k to take a course by one of my heroes. He's a brilliant man, but at the end of it I realized that he's making it up as he goes along like the rest of us.

Tech stack matters. OK I just said tech stack doesn't matter, but hear me out. If you hear Python dev vs C++ dev, you think very different things, right? That's because certain tools are really good at certain jobs. If you're not sure what you want to do, just do Java. It's a shitty programming language that's good at almost everything.

The greatest programming language ever is lisp. I should learn lisp.

For beginners, the most lucrative programming language to learn is SQL. Fuck all other languages. If you know SQL and nothing else, you can make bank. Payroll specialtist? Maybe 50k. Payroll specialist who knows SQL? 90k. Average joe with organizational skills at big corp? $40k. Average joe with organization skills AND sql? Call yourself a PM and earn $150k.

Tests are important but TDD is a damn cult.

Cushy government jobs are not what they are cracked up to be, at least for early to mid-career engineers. Sure, $120k + bennies + pension sound great, but you'll be selling your soul to work on esoteric proprietary technology. Much respect to government workers but seriously there's a reason why the median age for engineers at those places is 50+. Advice does not apply to government contractors.

Third party recruiters are leeches. However, if you find a good one, seriously develop a good relationship with them. They can help bootstrap your career. How do you know if you have a good one? If they've been a third party recruiter for more than 3 years, they're probably bad. The good ones typically become recruiters are large companies.

Options are worthless or can make you a millionaire. They're probably worthless unless the headcount of engineering is more than 100. Then maybe they are worth something within this decade.

Work from home is the tits. But lack of whiteboarding sucks.

At one of my former jobs, I had a four-day-week. I remember once being called on my free Friday by an agitated colleague of mine arguing that I crashed the entire application on the staging environment and I shall fix it that very day.

I refused. It was my free day after all and I had made plans. Yet I told him: OK, I take a look at it in Sunday and see what all the fuzz is all about. Because I honestly could fathom what big issue I could have caused.

On that Sunday, I realized that the feature I implemented worked as expected. And it took me two minutes to realize the problem: It was a minor thing, as it so often is: If the user was not logged in, instead of a user object, null got passed somewhere and boom -- 500 error screen. Some older feature broke due to some of my changes and I never noticed it as while I was developing I was always in a logged in state and I never bothered to test that feature as I assumed it working. Only my boss was not logged in when testing on the stage environment, and so he ran into it.

So what really pushed my buttons was:

It was not a bug. It was a regression.

Why is that distinction important?

My boss tried to guilt me into admitting that I did not deliver quality software. Yet he was the one explicitly forbidding me to write tests for that software. Well, this is what you get then! You pay in the long run by strange bugs, hotfixes, and annoyed developers. I salute you! :/

Yet I did not fix the bug right away. I could have. It would have just taken me just another two minutes again. Yet for once, instead of doing it quickly, I did it right: I, albeit unfamiliar with writing tests, searched for a way to write a test for that case. It came not easy for me as I was not accustomed to writing tests, and the solution I came up with a functional test not that ideal, as it required certain content to be in the database. But in the end, it worked good enough: I had a failing test. And then I made it pass again. That made the whole ordeal worthwhile to me. (Also the realization that that very Sunday, alone in that office, was one of the most productive since a long while really made me reflect my job choice.)

At the following Monday I just entered the office for the stand-up to declare that I fixed the regression and that I won't take responsibility for that crash on the staging environment. If you don't let me write test, don't expect me to test the entire application again and again. I don't want to ensure that the existing software doesn't break. That's what tests are for. Don't try to blame me for not having tests on critical infrastructure. And that's all I did on Monday. I have a policy to not do long hours, and when I do due to an "emergency", I will get my free time back another day. And so I went home that Monday right after the stand-up.

Do I even need to spell it out that I made a requirement for my next job to have a culture that requires testing? I did, and never looked back and I grew a lot as a developer.

I have familiarized myself with both the wonderful world of unit and acceptance testing. And deploying suddenly becomes cheap and easy. Sure, there sometimes are problems. But almost always they are related to infrastructure and not the underlying code base. (And yeah, sometimes you have randomly failing tests, but that's for another rant.)

Worst dev team failure I've experienced?

One of several.

Around 2012, a team of devs were tasked to convert a ASPX service to WCF that had one responsibility, returning product data (description, price, availability, etc...simple stuff)
No complex searching, just pass the ID, you get the response.

I was the original developer of the ASPX service, which API was an XML request and returned an XML response. The 'powers-that-be' decided anything XML was evil and had to be purged from the planet. If this thought bubble popped up over your head "Wait a sec...doesn't WCF transmit everything via SOAP, which is XML?", yes, but in their minds SOAP wasn't XML. That's not the worst WTF of this story.

The team, 3 developers, 2 DBAs, network administrators, several web developers, worked on the conversion for about 9 months using the Waterfall method (3~5 months was mostly in meetings and very basic prototyping) and using a test-first approach (their own flavor of TDD). The 'go live' day was to occur at 3:00AM and mandatory that nearly the entire department be on-sight (including the department VP) and available to help troubleshoot any system issues.

3:00AM - Teams start their deployments
3:05AM - Thousands and thousands of errors from all kinds of sources (web exceptions, database exceptions, server exceptions, etc), site goes down, teams roll everything back.

3:30AM - The primary developer remembered he made a last minute change to a stored procedure parameter that hadn't been pushed to production, which caused a side-affect across several layers of their stack.

4:00AM - The developer found his bug, but the manager decided it would be better if everyone went home and get a fresh look at the problem at 8:00AM (yes, he expected everyone to be back in the office at 8:00AM).

About a month later, the team scheduled another 3:00AM deployment (VP was present again), confident that introducing mocking into their testing pipeline would fix any database related errors.

3:00AM - Team starts their deployments.
3:30AM - No major errors, things seem to be going well. High fives, cheers..manager tells everyone to head home.
3:35AM - Site crashes, like white page, no response from the servers kind of crash. Resetting IIS on the servers works, but only for around 10 minutes or so.
4:00AM - Team rolls back, manager is clearly pissed at this point, "Nobody is going fucking home until we figure this out!!"
6:00AM - Diagnostics found the WCF client was causing the server to run out of resources, with a mix of clogging up server bandwidth, and a sprinkle of N+1 scaling problem. Manager lets everyone go home, but be back in the office at 8:00AM to develop a plan so this *never* happens again.

About 2 months later, a 'real' development+integration environment (previously, any+all integration tests were on the developer's machine) and the team scheduled a 6:00AM deployment, but at a much, much smaller scale with just the 3 development team members.

Why? Because the manager 'froze' changes to the ASPX service, the web team still needed various enhancements, so they bypassed the service (not using the ASPX service at all) and wrote their own SQL scripts that hit the database directly and utilized AppFabric/Velocity caching to allow the site to scale. There were only a couple client application using the ASPX service that needed to be converted, so deploying at 6:00AM gave everyone a couple of hours before users got into the office. Service deployed, worked like a champ.

A week later the VP schedules a celebration for the successful migration to WCF. Pizza, cake, the works. The 3 team members received awards (and a envelope, which probably equaled some $$$) and the entire team received a custom Benchmade pocket knife to remember this project's success. Myself and several others just stared at each other, not knowing what to say.

Later, my manager pulls several of us into a conference room
Me: "What the hell? This is one of the biggest failures I've been apart of. We got rewarded for thousands and thousands of dollars of wasted time."
<others expressed the same and expletive sediments>
Mgr: "I know..I know...but that's the story we have to stick with. If the company realizes what a fucking mess this is, we could all be fired."
Me: "What?!! All of us?!"
Mgr: "Well, shit rolls downhill. Dept-Mgr-John is ready to fire anyone he felt could make him look bad, which is why I pulled you guys in here. The other sheep out there will go along with anything he says and more than happy to throw you under the bus. Keep your head down until this blows over. Say nothing."

overheard someone say "test driven development is essentially 'debugging a system into existence'"

.... And to be honest I can't disagree, it's quite an accurate description of TDD.

I highly doubt that Apple does TDD.

Only write unit tests. It will be fine.

IF LIVES DEPEND ON A SYSTEM

1. Code review, collaboration, and knowledge sharing (each hour of code review saves 33 hours of maintenance)

2. TDD (40% — 80% reduction in production bug density)

3. Daily continuous integration (large code merges are a major source of bugs)

4. Minimize developer interruptions (an interrupted task takes twice as long and contains twice as many defects)

5. Linting (catches many typo and undefined variable bugs that static types could catch, as well as a host of stylistic issues that correlate with bug creation, such as accidentally assigning when you meant to compare)

6. Reduce complexity & improve modularity  -- complex code is harder to understand, test, and maintain

-Eric Elliott

We're looking for a ninja angular agile devops craftsman obsessed with TDD and OCD.

I extracted a tangled action to its own api, and wrote a test for it.

The test failed.

I added debugging, more debugging, all the debugging. It still fails. But I can at least see why it fails!

It turns out the api finds and updates the wrong user. It finds and updates the wrong user EVEN WHEN THERE ARE NO OTHER USERS.

WHAT THE SALAMI.

Also, the user lookup it uses is extremely roundabout and takes several seconds with ~2 million users. Normally I'd fix the lookup, but it has been in production for several years, and I'm terrified it will break something if I fix it.

Blargherhagrid.

*job ad* We strongly adhere to TDD

Reality:
Me: yeah but shouldn't we write tests first and then get X finished?
Manager: No takes too much time, we finish X and then we decide if it's worth testing.

Dear recruiters,
if you are looking for

- Java,Python, PHP
- React,Angular
- PostgreSQL, Redis, MongoDB
- AWS, S3, EC2, ECS, EKS
- *nix system administration
- Git and CI with TDD
- Docker, Kubernetes

That's not a Full Stack Developer
That’s an entire IT department

Yours truly #stolen

I just released a tiny game for iPhone!

It's basically an attempt to mix 'Heroes of Might & Magic' and mtg.

In the screenshot my terminal says 'helloworld.cpp'. That's right, this is my first c++ program and I don't care how crappy you think this game is, I'm super proud of myself!

I've always worked in data science where managers assume I know how to code because there's text on my screen and I can query and wrangle data, but I actually didn't know what a class was until like 3 years into my job.

Making this game was my attempt to really evolve myself away from just statistics / data transforms into actual programming. It took me forever but I'm really happy I did it

It was brutal at first using C++ instead of R/Python that data science people usually use, but now I start to wonder why it isn't more popular. Everything is so insanely fast. You really get a better idea of what your computer is actually doing instead of just standing on engineers' shoulders. It's great.

After the game was 90% finished (LOL) I started using Swift and Spritekit to get the visuals on the screen and working on iPhone. That was less fun. I didn't understand how to use xCode at all or how to keep writing tests, so I stopped doing TDD because I was '90% done anyway' and 'surely I'll figure out how to do basic debugging'. I'll know better next time...

Incorrectly used, every principle can cause damage.

What did we buy ?
Ryzen 9 and Radeon 6800 XT
What are we playing ?
Open TDD and factorio.

Yep, Can confirm, no lags.

My app does not need tests!

I jump on an existing scala project.

git pull && sbt compile test

Tests are failing.

Me: "Hey team, the tests are failing."

Team member: "That cannot be. They were passing for the the last run."

Me: "Did you run them locally?"

Team member: "No, on Jenkins. It was fine."

I check Jenkins.

Me: "What do you mean it's fine. The last successful deployment was on the end of May."

Team member: "The Pull Request checker always went through successfully."

I check how our Jenkins tasks are configured. It's true that the Pull Request Checker runs successfully yet due to a "minor misconfiguration" (aka "major fuckup") the Pull Request Checker only tests a tiny subset of the entire test suite.

Team members were were fine if their Pull Request got the "Success" notification on bitbucket's pull request page. And reviewers trusted that icon as well.

They never checked the master run of the Jenkins task. Where the tests were also failing for over a month.

I'm also highely confused how they did TDD. You know, writing a test first, making it green. (I hope they were just one specific test at a time assuming the others were green. The cynic in me assumes they outsourced running the tests to the Jenkins.)

Gnarf!

Team member having run the tests locally finally realizes: "The tests are broken. Gonna fix them."

Wow. Please, dear fellow developers: It does not kill you to run the entire test suite locally. Just do it. Treat the external test runners as a safety net. Yet always run the test suite locally first.

When I discovered Clean Code, design patterns, TDD and BDD. It just clicked. Ever since everything build so easy and obviously. I no longer have most of the code problems folks rant here about.

That's when it came to me: it's not enough to know how to write code. To climb off those amateur shoes I must adopt those methodologies, so that the code would be decoupled from me, from my style, and I've got to let tests drive my code rather than vice versa to have a flexible and reliable codebase that is cheap and easy to maintain/extend.

You study PHP, OO, Design Patterns, TDD, Zend Framework, Laravel, AngularJS...

Then you find a job, it's Wordpress...

[ Coworker walks up to my desk at 4:15 PM ]

Coworker: "Hey man. We had to make a few changes to the codebase because one of our unit tests were failing. Can you take a look at a pull request for me?"
Me: "Yeah sure, how many files?"
C: "About 600"
Me: [ thinking it might just be a ton of libraries or gradle shit] "...ooookaayyyy... that's a lot but doable... how many lines?"
C: “128,000 lines"
Me: "Fuck you"

When you learn to write tests..

Just finished my internship.

I entered knowing nothing and spent the entire year on solo projects.

My company does not use any frameworks because "they don't want to run code on a server that they didn't write", they use waterfall, only use version control on half the projects, use notepad++, never once even glanced at my code to check I know what I'm doing - even when i asked.

Also have never heard of a code review, have absolutely no QA in place other than the devs making it and quickly testing it visually, no requirements gathering - just pictures and have never heard of tdd.

Recently was given a project with no designs, no specs other than a verbal half thought out explanation and was dumped with random deadlines like "this needs to be demoed tomorrow night" with no idea about the project progression or what it looks like. Apparently it's all my fault that it failed.

I am very grateful to them for teaching me so much and giving me opportunities to teach myself on nice projects but come on.

What boggles my mind is that the company is 6 years old and has big, big clients. I don't understand how. I once tested a project about to go out the next day that had been "tested" and found pages of bugs. They would have lost the contract for sure...

This is how I feel while coding a system whitout tdd or any kind of tests, and it's the company's major system... Anyone else?

➡️You Are Not A Software Developer⬅️

When I became a developer, I thought that my job is to write software. When my customer had a problem, I was ready to write software that solves that problem. I was taught to write software.

But what customers need is not software. They need a solution to their problem. Your job is to find the most cost-effective solution, what software often is not.

According to the universal law of software development, more code leads to more bugs:

e = mc²

Or

errors = (more code)²

The number of bugs grows with the amount of code. You have to prioritize, reproduce and fix bugs.

The more code you write, the more your team and the team after it has to maintain. Even if you split the system into micro services, the complexity remains.

Writing well-tested, clean code takes a lot of time. When you’re writing code, other important work is idle. The work that prevents your company from becoming rich.

A for-profit company wants to make money and reduce expenses. Then the company hires you to solve problems that prevent it from becoming rich. Confused by your job title, you take their money and turn it into expensive software.

But business has nothing to do about software. Even software business is not about software. Business is about making money.

Your job is to understand how the company is making money, help make more money and reduce expenses. Once you know that, you will become the most valuable asset in the company.

Stop viewing yourself as a software developer. You are a money maker.

Think about how to save and make money for your customers.

Find the most annoying problem and fix it:

▶️Is adding a new feature too costly? Solve the problem manually.
▶️Is testing slow? Become a tester.
▶️Is hiring not going well? Speak at a meetup and advertise your company.
▶️Is your team not productive enough? Bring them coffee.

Your job title doesn’t matter. Ego doesn’t matter either.

Titles and roles are distracting us from what matters to our customers – money.💸

You are a money maker. Thinking as a money maker can help choose the next skill for development. For example:

Serverless: pay only for resources you consume, spend less time on capacity planning = 💰

Machine Learning: get rid of manual decision-making = 💰

TDD: shorter feedback cycle, fewer bugs = 💰

Soft Skills: inspire teammates, so they are more productive and happy = 💰

If you don’t know what to learn next — answer a simple question:

What skills can help my company make more money and reduce expenses?

Very unlikely it’s another web framework written in JavaScript.

Article by Eduards Sizovs
Sizovs.net

So...

I'm looking for my first job as a web developer. I kept seeing these rants about how horrible and frustrating job searching is, all of which I thought were greatly exaggerated. They're all just jokes and memes, right?

Nope.

Every fucking meme seems to be true.

- Junior developer with +4 years of experience, expert in their field - check!

- Listing requirements for 6 different jobs under "Full-stack developer" - check!

- "Expert developer required ASAP" - $10/hour - check!

- 100% remote ... *scrolls all the way down* ... for 2 days of the week - check!

- Entry level font-end position - must be an expert in Vue, Angular, React, AWS, Drupal, Wordpress, PHP, Python, ES9+, OOP, TDD, BDD - check!

- "Cool" description written in js code with no indentation - check!

And I'm not seeing these every once in a while or something like that. No. Most of the posts are like this. I thought I may just be underqualified since I've never had a real job before, but this just seems crazy to me...

Guy: - Why the hell do you keep adding new tests with "TDD" in the commit log? Is this because you're wearing this stupid TDD t-shirt!? You're only supposed to maintain this! There's nothing to develop! Nothing here will ever be test-driven!

Cprn: (turns around)

T-shirt: *Technical Debt Development*

"We don't have time for writing tests"
"Yeah we could write them but only if the client paid us for that"
"You can just test new features manually!"

- Most devs of our mobile team.

Every day they're fighting with bugs and when they're fixed, a couple more pop out of nowhere.

Dear god help me.

After 10 years of development, and 7 years of being happily married, I'm in love again... With Unit Testing.

Based on a true story:

Me: Woah, I can't believe you wrote a test for such an edge case, you really take TDD seriously

... 1 minute later

Me: Woah, I can't believe this is the only test for the whole project

Last meeting I suggested we started using unit test and perhaps TDD on our platforms.

My boss is open to it and everyone seems to like the idea...

Now I just discovered that our dumbass coworker is trying to say by my back that its a bad idea to double the code efforts and that he sees no point in it...

Well dumbass cock sucker who can't even fucking remember how to write `docker-compose up` without messing things up you can fuck your self because you are certainly gonna be fucked sideways untill the end of the year.

Had a 1:1 with my boss last night and together we figured out a tricky bug related to my PR. However, either my PR or that bug patch broke a tangentially-related test. Queue my usual exhaustion, and I gave up trying to fix it.

This morning, I'm looking at it and nothing makes sense. My change should not have broken the test. So I reran the controller's tests, and... they all pass?

What is logic.

Good thing, though; that test leads to a few rabbit holes I haven't even begun exploring yet.

Oh, never mind. It broke again.
Ergh, here we go. 😔

Just need to get this off my chest. Started a new job 3 weeks ago at a company that has been around ~18 years, it is only recently that they have started to grow more rapidly. I was brought in under the guise that they wanted to embrace change and better practices and so said I was up for the challenge.

In my 2nd week I was asked to produce a document on tackling the technical debt and an approach to software development in the future for 3 consultants who were coming in to review the development practices of the company on behalf of the private equity firm who has taken a major stake in the company. I wrote the document trying to be factual about the current state and where I wanted to go, key points being:

Currently a tightly coupled monolith with little separation of concerns (73 projects in one solution but you have to build two other solutions to get it to build because there are direct references.).

Little to no adherence to SOLID principles.

No automated testing whatsoever.

Libraries all directly referenced using the file system rather than Nuget.

I set out a plan which said we needed to introduce TDD, breaking dependencies, splitting libraries into separate projects with nuget packages. Start adhering to SOLID principles, looking at breaking the project down into smaller services using the strangler pattern etc. After submitting what I had written to be part of a larger document I was told that it had been tweaked as they felt it was too negative. I asked to see the master document and it turns out they had completely excluded it.

I’ve had open and frank discussions with the dev team who to me have espoused that previously they have tried to do better, tackle technical debt etc but have struggled to get management to allow them. All in all a fairly poor culture. They seem almost resigned to their fate.

In my first 2 weeks I was told to get myself acquainted and to settle myself in. I started looking at the code and was quite shocked at how poorly written a lot of it was and in discussions with my manager have been critical of the code base and quite passionate and opinionated about the changes I want to see.

Then on Friday, the end of my third week, I was invited to a meeting for a catch up. The first thing I was told was that they felt I was being too openly critical in the office and whether I was a good fit for the company, essentially a stay or go ultimatum. I’ve asked for the weekend to think about it.

I’ve been a little rocked by it being so quickly asked if I was a good fit for the company and it got my back up. I told them that I was a good fit but for me to stay I want to see a commitment to changes, they told me that they had commitments to deliver new features and that we might be able to do it at some point in the future but for now I just needed to crack on.

Ordinarily I would just walk but I’ve recently started the process to adopt kids and changing jobs right now would blow that out the water. At the same time I’m passionate about what I do and having a high standards, I’m not going to be silenced for being critical but maybe I will try and tackle it in a different way. I think my biggest issue is that my boss who was previously a Senior Developer (my current position) has worked at the company for 12 years and it is his only job, so when I’m being critical it’s most likely criticising code he wrote. I find it hard to have the respect of a boss who I had to teach what a unit test was and how to write one. It makes it hard to preach good standards when by all accounts they don’t see the problems.

Just wondering if anyone has suggestions or experience that might help me tackle this situation?

I think I'm falling in love. With TDD.

I used to be very skeptic about it. You know, the usual reasons: it takes longer to deliver, constant "flow" interruptions, etc, etc. But ever since I've tried it I'm nothing but happy about my choice :)

I'm moving forward, I'm not making any regressions, I'm no longer afraid to make any changes in my code as I know tests will show what exactly I break,.. And most importanty, I have all use-cases with corner-cases defined and "explained" in the code... No more do I have to search in Confluence for how this exact scenario should behave. Everything is here. Everything's in the tests.

It's amazing!

Yeah, it DOES take longer to deliver so if you're hardcore Agile living by "Ship it as soon as it compiles" TDD might be too slow. But if you prefer knowing when your code is covering all the use cases w/o any errors -- TDD is the way.

Bob Martin. His books Clean Code and the Clean Coder, and all his talks on architecture, SOLID and TDD. I could listen to him talk for days, and he taught me everything i know about writing clean code.

a little confession: i've rarely used test suites in my projects (due to laziness and lack of time).

i've started a new project and now i HAD to write tests in order to make my PM happy.

Then i had to refactor a lot of code.

IT WAS SO EASY WITH TESTS.
I WAS A FOOL.
STUPID PAST ME, STUPID!

I love TDD.

It's so relaxing to know that your fix didn't fuck up anything else when the tests pass.

Working in the embedded systems industry for most of my life, I can tell you methodical testing by the software engineers is significantly lacking. Compared to the higher level language development with unit tests and etc, something i think the higher level abstracted industry actually hit out the of park successfully.

The culture around unit testing and testing in general is far superior in java and the rest.

Down here in embedded all too often I hear “well it worked on my setup... it worked at my desk”.. or Oh I forgot to test that part.. or I didn’t think that perticular value could get passed in... etc I’ve heard it all. Then I’ve also heard, you can’t do TTD or unit tests like high level on embedded... HORSESHIT!

You most definitely can! This book is a great book to prove a point or use as confirmation you are doing things correctly. My history with this book was I gonna as doing my own technique of unit testing based on my experience in the high level. Was it perfect no but I caught much more than if I hadn’t done the testing. THEN I found this book, and was like ohh cool I’m glad I’m on the right thought process because essentially what they were doing in the book is what I was doing just slightly less structured and missing a few things.

I’ve seen coworkers immediately think it’s impossible to utilize host testing .. wrong.

Come to find out most the of problems actually are related to lack of abstraction or for thought out into software system design by many lone wolf embedded developers.. either being alone, or not having to think about repercussions of writing direct register writes in application or creating 1500 line “main functions” because their perception is “main = application”. (Not everyone is like this) but it seems to be related to the EEs writing code ( they don’t know wha the CS knows) and CS writing over abstraction and won’t fit on Embedded... then you have CEs that either get both sides or don’t.. the ones to understand the low level need but also get high level concepts and pariadigms and adapt them to low level requirements BOOM those are the special folks.

ANYway..the book is great because it’s a great beginner book for those embedded folks who don’t understand what TDD is or Unit testing and think they can’t do it because they are embedded. So all they do is AdHoc testing on the fly no recording results no concluding data very quick spot check and done....

If your embedded software engineers say they can’t unit test or do TDD or anything other than AdHoc Testing...Throw the book at them and say you want the unit test results report by next week Friday and walk away.

Lol

Greatest productivity hack?

TDD

> Last year wrote a unittest - I was asked to delete it
> no design patterns. Not a single one
> no encapsulation
> fucked up inheritance [I had no idea it was possible at all...]
> generics every-fucking-where
> I could go on...

this month the lead dev was not in and I had to make a new feature. Guess what I did :)

tdd [coverage >90%], a couple of builders, a factory or two, two composites, one decorator, only a few generics - only where really needed. Private fields, not a single @Autowired field [they were fucking my tdd], nicely abstracted integrations, and so on. Everything is writen according to clean code: max 10loc methods, <140col lines, reusable constants and utils, SOLID as a rock, etc.

Due date is next week. Took me 3 weeks to craft it.

Guess who's gonna be piiiiiiiiiiiiisssedd 😁

the best part - I don't even work there, our company was hired for xx hours as helping hands 😁

that's not all. They have like 6 envs and their deployment is all-fucking-manual. Will try to learn how to dockerize that app and deploy it on docker. Gosh I wish I could see his face when he's back 😁

p.S. From ethical point of view, he's the only dev who believes his code is perfect. No other dev in the team agrees. AND he once said: 'it's gonna be my way or no way at all'. So I don't think I did wrong... Did I? :)

Sometimes I really fucking hate this company

The code is an absolute shitshow filled with static classes, untestable and duplicate code, on top of that my boss doesn’t like open source

Yeah so i’m not allowed to use a mapping library or something because “Uhhh like uhh we don’t have a contract with the company so who knows what’ll happen when the maintainers leave the project”
I understand his reasoning but it’s an absolutely retarded reasoning especially considering most of the .NET platform is open source nowadays

Writing a webapp from scratch now as well and I HAVE to use vanilla javascript and AngularJS 1.5 even though all the developers here told me they would like to upgrade to Typescript and Angular 2+ but it’s never gonna happen I suppose

Oh and he doesn’t like TDD and our only product is SAAS so imagine the amount of bugs being pushed simply because we don’t have time to write tests or even manually test, let alone refactor our horseshit codebase

AND i have to pay for gas myself which takes 200€ out of my bank account a month just for driving to work whilst I’m only getting a mediocre pay

Have a job interview tomorrow and another one on tuesday

trust my unit tests

The day your boss tells you tests are some kind of self-satisfaction for developers and asks you to focus, to not introduce bugs.

College rant:

I have finals next week. I am sitting here learning about things which have no benefit to my career. My college requires me to take Calculus based physics 2, which makes no sense to me at all! I do appreciate physics however I would much rather be coding. In my CS courses you learn theory which is fine, however very impractical. I last October I realized how much more you need to do and a degree just won't cut it. I spend about 50 hours a week learning TDD, git, hashes all this stuff that is not taught in school. Then on top of this I'm learning pointless crap that if I ever needed in a real world situation I would go to Kahn Academy or simply Google it. I'm upset because I have to stop coding for the week to study information I will forget 2 weeks from now, and most likely never use again. I have a job someone offered me which will be extremely beneficial to my career however I have to wait a week to even look at it. I'm just bitter.

Whats worse than TestDrivenDevelopement?

Starting TDD once a 15K LoC project has well started...

sooo.... here I am testing the entirity of clinl ;_;

!rant
With all the people around here ranting about their PM's, I'm really curious to see how a PMRant app would look like. What are they complaining about?
Devs that listen to music all day long and never want to be disturbed?
Engineers who talk in long, incomprehensible words?
...TDD taking too long?

Best quote of the conference: If you are writing code without using TDD it's called developing if you are using TDD it's called engineering

I love Test-Driven Development!

And because of that fact, my heart shatters into thousands of pieces, when I recognize error events on our production nodes which are pointing onto a golden hammer function in a legacy project.

This particular function has about 300 lines with a bunch of subfunction calls and instantiations of helper-classes returning information for workflow.

Refactoring this code to apply proper unit-tests requires a way bigger investment than simply deal with 30 eventlogs a day, because this kind of payment is barely used by customers of our webshop.

This fact is a little itch each day of my work.

Guess it will make me go insane one day
¯\_(ツ)_/¯

xD

Has this ever happened to any job applicant here:

Job requirements:
Java, angulaj js, TDD, node js and demonstrated usage of noSql DBMS.

You qualify for the job and only to find the work mainly requires php

Inspired by @Billgates

everyone around is hyped about new tech they get to use, new toys to tinker with, I can see their eyes shining when they hear "let's try and introduce kafka" - they would wiggle their tails all day long if they had ones!

And me? Well, a new potential employer got me so excited I couldn't wash a smile off my face for a few days! You know what they said? "we don't use any frameworks, we focus on clean code, solid, kiss and we write with tdd". Bare java - that's the best position I've heard of in years!

I guess I'm oldschool. But I truly believe their approach is the right one. Not trashing the code with spring [which is turning into smth what systemd is for linux/unix], hibernate and what not.

Just good old java code. Db, multithreading, request-mapping -- all plain, manual and simple.

Amazing!

When people use Thread.sleep in unit tests to delay execution of threads

I wish I could do TDD on my life decisions

The guy who became my manager just pushes to the prod branch.

On a repo where another team clearly set up development and production branches.

This guy has been pushing code like crazy and I always wanted to take my time setting things up properly in our team: TDD, CI/CD, etc.

Because he pushed so much he became my manager and I was seen as unproductive.

Data Science and software development best practices just dont coexist it seems.

Yeah yeah, it's up to me to start introducing good practices, but atm "getting it done" takes priority over the real based shit.

Forget TDD, BDD...
Use GDD.
(Google Driven Development)
:P :D

Man I really wish I knew how to implement TDD. Sounds so good in theory, seems impossible in practice 😅

When you finally see a series of ✓'s across all tests - today is a good day!

Now to write a whole bunch more that......, that dickhead past @C0D4 didn't do.

So... Heard back from a recruiter today. Lovely lass.

I’d passed over a submission for her tech demo.

The brief was basically just to create a small simple module that calculates shit, nae effort.

But, when the recruiter had me on the phone she said “I know it’s a silly small module but try and run it up like you would a production ready app”.

The job spec and recruiter were keen on me demonstrating TDD, not specific on js version, final runtime, etc. The job was a senior spec at a higher salary range. So it warranted some effort, and demonstrating more than a simple module.

“Okay, cool, nae bother, let’s crack on.”

The feedback in the response from the dev today:
“He’s over-engineered tests, build...”

SUCK MY LEFT TESTICLE YOU FUCKWIT.

Talk to your recruiters, not me.

The feedback included a phrase I never hope to hear from a developer I work with:
“Tests are good but...” 😞

It was a standard 98% test suite from an RGR cycle, no more or less than I’d expect in prod.

The rest of the feedback was misguided or plain wrong. It was useful to see because I know now when they say they have “high standards” they mean: we listen to the dude who put the factory pattern in a JS brief.

Oh shit also: “someone’s done chmod 777” was in there as a sarcastic comment in the feedback. It was his fucking unarchive tool 😞

My response was brief and polite: “cheers for the consideration, all the best, James”

It’s honestly not worth warning them. Or, asking why they’d criticise something they’d asked me to do.

If you want a shitty js module, ask for a shitty js module and no more.

TDD.

I'm a fan of writing tests right after you write every module. I actually think it's doable.

But I'm not a big fan of traditional TDD, which is defined as: first writing the tests, making them fail, writing code until tests don't fail.

My experience with traditional TDD when writing library code is that you start with this very naive idea of what is needed, so you write classes and functions and a lot of times they look like overly simplistic pseudocode.

So what do you do? You scratch that, you delete those classes/functions several times.

I think this discovery process that your code is naive is slowed the fuck down by doing TDD.

I'd rather write a theoretical API in a readme file, then write code, and then write the tests, you can even withhold writing the tests, but never leaving them for another day, just so that you don't waste time writing tests that you're going to scratch.

There's always a time constraint, and most of us can't afford bikeshedding.

Traditional TDD feels like an esoteric thing, it tries to make programming a series of steps, it actually sounds like an infommercial.
"FOLLOW THESE 3 SIMPLE STEPS AND WRITE THE BEST CODE EVER"

finally someone said it

Arrrrg. API change totally broke my library and 8 out of 149 tests are failing...

"Let the developers consider a conceptual design,” the King said, for about the twentieth time that day._

“No, no!” said the Queen. “Tests first—design afterwards.”

“Stuff and nonsense!” said Alice loudly. “The idea of writing the tests first!”

“Hold your tongue!” said the Queen, turning purple. “How much code have you written recently, anyway?” she sneered.

“I won’t,” said the plucky little Alice. “Tests shouldn’t drive design, design should drive testing. Tests should verify that your code works as it was designed, and that it meets the customer’s requirements, too,” she added, surprised by her own insight. “And when you drive your tests from a conceptual design, you can test smarter instead of harder.”

tfw...

• the new "sr dev" asks what the point of TDD is
• being polite, I answer in an ELI5 format
• rest of the room nods head in agreement
• new "sr dev" still has baffled look on face

I really like this book on the basis of the philosophy overall, no this doesn’t solve all problems but it’s a good baseline of “guidelines/rules” to program by. Good metrics or goals to architect and design software projects high and low level projects.

Fight Software Rot
Avoid duplicate code
Write Flexible, dynamic, adaptable code
Not cargo cult programming and programming by coincidence.
Make robust code, contracts/asserts/exceptions
Test, Test, and TEST again and Continue testing.. this is a big one.. not so much meaning TDD.. but just testing in general never stop trying to break your software.. FIND the bugs.. you should want to find your bugs. Even after releasing code the field continue testing.

No wonder why people get hooked on TDD.

Passing tests are like crack to me right now

My boss always like to say: damn, every time we fix something something else breaks.

And I always tell him about TDD, unit tests, etc...

He smiles and continues to work as if nothing have been said...

He sits behind me and is constantly "wtfucking" and I'm here just thinking that he might have broken something that could have been avoided if he listened to me.

We are working on separate projects now and every time I think that someday I'm gonna join that code it gives me goosebumps 😵😓

> Run 'All Tests' with Coverage

No tests failing
Coverage >95%

Hell yeah! I've tasted TDD and I don't want to look back!

"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!"

Am I the only one who gets extremely nervous the night before an interview as that technical test can encompass the entire academic field of CS. I'm just worried I'll forget the difference between a clustered and non-clustered index or fail to convey the difference between TDD and BDD.

I'm ten years in to my career now, so I 'should' know my stuff. I've produced the tests my self, hired other devs, but I still feel the nerves.

Our team(except one guy) does follow TDD, it may or may not be the best but solves for us in most cases.

This one guy follows HDD : Hope Driven Development.
He writes some code, checks_in and HOPE it works :-)
And breaks preprod almost once per week.

So our HR have recently started to enforce arrival/departure time while also giving us a room for freedom (we can be at work from 7:30 till 9:00 and leave accordingly from 4:30-6:00)
So 2 weeks ago my manager asked me why on a date I didn't checkout/checkin, I looked out in my vacation log and sure enough it was a day off. I said to myself maybe be ause this day was requested last year they didn't remember it no problem
Anyway fast forward to today and my manager asked me why on the 25th of January I left (early) at 1?
What? I don't remember leaving early except for one day last week (Feb 7-personal reasons and was requested days before)
So i check my vacation log to see if I forgot something and i see that Jan 25 is a Saturday. We don't work on Saturdays! I go and check with my manager telling him that.
Then it hits me. I checked my taxi app and on Sat Jan 25 I had a ride at 1:22 AM!! from work to home. Yes i remembered that on that day I had to stay late for a project
WTF HR??!
Sorry for the long post

Does anyone get the feeling that as they become more senior, they care less about meeting "best practices" and more of just "good enough"?

Best practices being everything in those books about TDD, unit testing, design patterns, design artifacts.

Good enough: enough so it won't blow up in prod, some tests but not 80-90%, some docs. Basically not like those public docs, open source projects/frameworks where function is covered

When I first started professionally, I was all about efficiency, good design, reducing technical debt, clean code.

But now, I look at problems and instinctively I may make these decisions but I don't really think about it much. First goal is to just get something working, clean it up later... Maybe.

I'm finally writing unit tests consistently thanks to a simple file organization decision.

I'm not doing pure TDD, but at least I'm writing the tests immediately after writing a module, and I make sure they run ok.

What I'm doing is Instead of putting the test files in a "tests" dir at the root of the project, I have the tests right next to the source code.

So if I have a dog.x file, I also have a dog.test.x file next to it.

I'm not inventing gunpowder here. I've seen several people do this.
But it's something that is not generally made a default or advised to do.
Like I said; test frameworks in general go with the classic "tests" dir.

But for me this is day and night in whether I write the tests or not.

Which makes sense. Imagine the classic scenario of the "tests" dir, and you just created a file deep into a hierarchy, let's say src/lib/console/windows/dog.x

This means that if you want to write tests for that, you need to make sure the hierarchy tests/lib/console/windows/dog.test.x exists

If the test file already exists, but you want to access both files, you need to traverse deep for each.

Also, it's actually harder to keep track which files have unit tests and which do not.

Meanwhile, if the test files are next to the source, all these problems disappear.

That doesn't mean there are no other challenges with testing, like testing untestable things, like system calls or http requests, but there are ways to deal with that.

unit testing

Jest? It's the perfect name for a testing library, because I certainly feel like a clown! 🤡

#clowndrivendevelopment

Hmm. So have you ever argued in a job interview? Like really standing your ground? In a technical interview?

Today I had a live coding session with a company I'm interested in. The developer was giving me tasks to evolve the feature on and on.

Everything was TDD. Splendid!

However at one point I had to test if the outcome of the method call is random. What I did is basically:
```
Provider<String> provider = new SomeProvider("aaa", "bbb", "ccc", "ddd", "eee", "fff")

for(int i=0; i<100; i++) {
String str = provider.get();
map.put(str, incrementCount(str));
}
Set<Integer> occurences = new HashSet(map.values());
occurences.removeIf(o -> o.equals(occurences.get(0)));
assertFalse(occurences.empty());
```
and I called it good enough, since I cannot verify true randomness.
But the dev argued that this is not enough and I must verify whether the output is truly random or not, and the output (considering the provider only has a finite set of values to return) occurences are almost equal (i.e. the deviation from median is the median itself).

I argued this is not possible and it beats the core principle of randomness -- non-determinism. Since if you can reliably test whether the sequence is truly random you must have an algorithm which determines what value can or cannot be next in the sequence. Which means determinism. And that the (P)RNG is then flawed. The best you can do is to test whether randomness is "good enough" for your use case.

We were arguing and he eventually said "alright, let's call it a good enough solution, since we're short on time".

I wonder whether this will have adverse effect my evaluation . So have you ever argued with your interviewer? Did it turn out to the better or to the worse?

But more importantly, was I right? :D

So, I've been working as a developer for 15 years almost. I recently started what could reasonably be described as my dream job. As in absolutely fucking awesome. Really interesting product, sane technology, nice co-workers, decent salary, 100% remote.

So, why am I suffering from motivation issues? I find it difficult to get started on the simplest tasks. and looking at the check-ins from my coworkers is intimidating. I had a phase of burnout previously so I'm watching that in myself too...

So far the best solutions I've found are.
1 Coffee, lots of coffee.
2 quick catch-up calls so that I'm reassured I'm actually doing the right work and the quality is good enough.
3 following TDD strictly and not thinking too far ahead on each iteration. (I recommend "99 bottles of OOP")

The "unit" in unit test does not mean your ENTIRE APPLICATION. Ever heard of scope!?

I am amazed how often people write overblown test setups, mock hundreds of unrelated services, just to test one tiny bit of logic.

That bit of logic could have been a pure function.

For that pure function you could write a dead simple unit test. Given that input, I expect that output. Nothing more, nothing less. (It helps even more if the pure functions only accepts primitives, like string and numbers, or very simple immutable value objects).

No I don't care that the service is used by another service, as your mocked interaction also doesn't test the service as a whole but you just assume the happy case most of the time anyway. You want to test the entire application? Let's not use unit tests for that but let's use a different kind of test for that (integration test, functional tests, e2e-tests).

If you write code in a way that easily allows for unit testing, your need to mock goes away.

As I was refactoring a class in a TypeScript project, I changed calls from `this.config` to `this.getConfig()`.

Suddenly, the tests were failing as somehow the live credentials were used from within the test.

Digging deeper I discovered this.

interface Base {
public config;
public getConfig();
}

So far so good. Wondering why config needs to be public, though nothing too shabby, let's look further:

class MyImpl implements Base {
constructor() {
this.config = this.getConfig()
}

getConfig = () => someGlobalVar;
}

┻━┻︵ \(°□°)/ ︵ ┻━┻

Why would you do this? This breaks dependency injection completely.

In the tests, we were of course doing:

testMe = new MyImpl();
testMe.config = testConfig;

So even though you have a getter, you cannot call it safely as the global var would take precedence. It's rather used as a setter within the constructor. WTF.

Sad part is that this pattern is kept throughout the entire codebase. So yeah for consistency!?

(And yes, I found a quick workaround by doing

getConfig = () => this.config || someGlobalVar;

though still, who in their right mind would do something like this?)

How to make BILLIONS with a coding blog:

1. make a post with a controvertial title like "IS TDD DEAD?"
2. write an article concluding that the controvertial statement is, in fact, wrong, like "Nope"
3. Drown in monies from ads

When it finally clicked on how to write tests first and I could actually make code progress with it.

I’m so sick and tired of the cattle-minded people in the software world. I love coding and improving myself; I've got over 18 years of experience. I enjoy what I do, and I like being good at it. I know my way around a variety of different technologies, and I could easily outperform most engineers with similar experience. If I don’t know something, I get excited to learn and I ask questions. I don’t enjoy standing in the spotlight about what I know; I prefer supporting, helping, solving problems, improving solutions, and simplifying everything.

From my experience, the best solution is the simplest, shortest, fastest, and leanest one. But unfortunately, there are people in the workplace who think the opposite of me and blindly follow this so-called prophet named Uncle Bob, zealously writing all his SOLID principles and dogmatic code, turning their work environments into a toxic mess. I’m so done with it. You have no idea how harmful a person can be when they cling to the teachings of a guy like Uncle Bob—someone who probably hasn't even written the "s" in software himself and is just trying to sell his book. In almost every job or team I join, there’s one of these people who drags junior developers into writing dogmatic code by chanting about SOLID principles, Uncle Bob, and object-oriented programming.

Software engineering isn’t something you can learn from a book written by people like Uncle Bob, who haven’t coded a decent product in a real development process. Experience is something entirely different, and from my experience, everything taken to extremes turns out badly. Wherever I see an Uncle Bob disciple, the work inevitably slides into the extremes. For someone writing in C and C++, it’s disheartening to hear about object-oriented programming, SOLID principles, and agile nonsense. I’m tired of seeing people cluttering their code with interfaces for every little thing, over-engineering patterns, and stuffing every piece of code with interfaces to make it “testable.” They run around claiming they’re writing SOLID code, doing TDD, following “best practices,” yet they can't solve any real problems or algorithms. They take a week-long task and drag it out to six, making simple things complex and distancing themselves from real solutions. I’m sick of these types.

If you’re a junior developer, please ignore the fools trying to lead you down this path, and don’t become dogmatic about what you learn, especially if you’re writing C++.

I’ve never seen any real engineer who takes this SOLID, object-oriented nonsense seriously. Believe me, once you reach a certain threshold, you won’t hear these words anymore. Software isn’t just about that. Object-oriented programming, especially if you’re not writing Java or C#, and especially if you’re working in C++ (thankfully, C doesn’t even have it), is something you should definitely steer clear of. Robert C. Martin, aka Uncle Bob—if only you had written your book with a focus on Java or C#. These dogmatic code writers with 7-8 years of experience crying at the sight of free functions in C++ really give me a headache. Because of you, these people exist, and I don’t have the energy to deal with this nonsense at my age.

Developing in TDD.

Always test your fucking mocks
I spent 3 weeks debugging every part of the application, except for the mock network connection. The mock network connection didn't trigger closing events on the sender side.

So I am finally plunging into continuous integration. If I make one more deploy script mistake, I've lost enough time to merit having learned a better solution than bash scripting calling git and rhc and py files I wrote. I have failing tests that are failing because they weren't updated after the million and a half urgent changes in the past 2 months, so it's time to act like I am a TDD fanatic and write the tests correctly. So much work. All from me listening to the constant req changes, listening to the urgency, letting non-devs get under my skin if you will. I'm optimistic in all the wrong places - I think I can write that by end of day let's try it. I'm lazy in the wrong places - I think that I can write that test later, because all I changed was XYZ (which took all night but I said I'd get it as close as possible didn't I?). And I think these handful of bash scripts are good enough to make sure I run tests? But remember, I didn't write the tests or I didn't go back and update them. Or the tests that fail, I'm too lazy. And so much of the tests, I would need to use, idk selenium for, and damnit if I really don't want to dig for element IDs to wait for every time I need an AJAX call.

Okay wow, I really did rant here. And discredited myself a bit lol I need to ignore the wrong lazy and embrace the right lazy. Protect myself from myself and from contributors. It really is, up to me now, to rescue myself from my bad habits. Bad habits perpetuated by clients urgency every day, to change things, that should have been finalized in November if we wanted a stable flipping system in January. It feels like the blind (client) leading the blind (me, when I do dumb shit like rush features out the door half tested).

Anyway all this came out, because I have been reading about continuous integration and stumbled upon this quote. And thought someone might laugh at the anachronism like I did

I tripped too🤦‍♂️

aahh, that's a nice feeling!

Half a year ago I was borrowed to a client's team as a pair of helping hands on one project. Today I pulled that project source again to see what has changed.

The only things changed in my code are typos in strings (missing space, missing letter, etc.). Not a single error in actual code.

Maybe >90% TDD tests coverage has smth to do with it ;)

aahhh, that's a nice feeling :)

That feeling when something you write works, and every part is tested. And your happy with it

Our team - if ever existed - is falling apart. Pressure raising. Release deadline probably failing. No release ready for Big Sur.

Almost seemed we were getting somewhere: More focus on code quality, unit tests, proper design, smaller classes. But somehow we now ended up in "microservice" hell; a gazillion classes, mostly tested in isolation, but together they just fail to do their job. A cheap and dirty proof of concept from March is still more capable than this pile. I really start to doubt all that "Clean code", TDD, Agility rhetorics. What does it help you, if nobody cares for the end result? It's like a month I try to hammer down that message: we have to have testable artifacts, we have to ensure code signing works, our artifact is packaged and installable, we have to give QA something they can test - but time just passes and this piece of shit software is still being killed or does nothing.

Now my knee is broken and can do no sports and are tied to my chair even more. To top it all my coffee machine broke and my internet connection was abysmal this week. Not the usual small disconnects, after which it would recover, but more annoying and enduring: often being throttled to 1.7 MB/s (ranking my connection in the slowest 7% even in Germany). My RDP sessions had compression artifacts all over the screen and a mouse click would only take effect 5 sec later.

But my Esspresso machine was just repaired. Not all hope is lost.

amirite?

Don't reuse your fixtures!

Each test case should be isolated. Don't ever think just because some function requires a similar input, it's safe to reuse it ALL OVER THE PLACE.

Why? Because someday, you want to change one functionality of one unit.

And you adapt your tests, fix your code, and suddenly, by changing one fixture, you break dozens if not hundreds of unrelated tests and now you have to clean up that mess.

It's even worse for functional tests with all those interwoven parts so that it becomes hard to reason about the scope of your tests when lacking proper documentation.

How I know? BECAUSE I AM CLEANING UP YOUR MESS RIGHT NOW!

I'm going to be that guy .... A lot of these rants are about code compiling first time .. Throwing away code you wrote because you didn't need it... Getting in the zone and writing a billion lines before you compile .... Am I the only freaking person here that does TDD ? My rant is wake up people ! People evangelize about it because it fucking works !

Most satisfying bug I fixed?

Indentation bug in python after searching hours for the bug. Yes, indentation bugs still happen in 2018. Thanks to TDD I failed fast otherwise it would take way longer to find the bug.

TDD has not been proven in studies to provide substantial reduction in cyclomatic complexity or other metrics of software development.

1. Be better dev/human
2. Do all personal projects TDD
3. Finish that unreal engine course that i bought last year january

Taming a legacy system with the team using TDD and great refactoring techniques

My Dev hero is without a doubt Robert C Martin (Uncle Bob). His books clean code and the cleans coder changed the way I program and his work on TDD too

Roger that!

Impossible changes become possible.

Going through the conversation for xxxxth time with my business partner, why we will not launch a new product on top of pre-made PHP script / plugin.

Just got our company into TDD, and automated QA via CI server & code checks etc, PLEASE stop trying to drag us back into the land of spaghetti code & bug legions in production. That's all thxbye.

Is it weird that I'm excited to get to test my code for my side project that I'm working on? It feels like I should hate this since I'm going to graduate next year and my career will be doing this as a job. Really, though, I'm glad to make sure my code is designed properly. It gives me confidence in my programming skills. BTW, if anyone is trying to use a build tool in Python there are NO guides to get started that I've seen! I had to go through trial and error to get pybuilder running!

How seriously do you take TDD, CI/CD, automated testing, clean commits, good architecture, Agile, low coupling/high cohesion, etc ... ?

How much time do you invest in those things if you have a deadline up ahead?

Have you seen these things being valued or disregarded at the previous companies you worked for?

You may know I love to hate tests. Well not the tests actually, what I hate is the TDD culture.

DBMS schema in my app dictates a key can either have a value, or be omitted - it can't be null, and all queries are written with that in mind (also they're checked compile-time against schema). But tester failed to mock schema validation, inserted a bunch of null keys with mock data, actually wrote assertions to check those keys are null (even though they never should be), and wanted me to add "or null" to my "exists" queries.

No, we don't need more tests, and you're not smart with your "edge cases" argument. DBMS and compiler ensure those null values can never exists in our DB, and they're already well tested by their developers. We need you to stop relying on TDD so much you forget about the practical purpose of the code, and to occasionally break from the whole theoretical independent tests to make sure your testing actually aligns with third-party services some code uses.

And no, we don't need more tests to test your mocks, and tests to test those test, and yo dawg, I heard ...

Cocktail for disaster:

- TDD
- Mocking
- Multithreading
- Averagely well written, testable code
- All tests pass
- One test methods still shows some vague stacktrace in a worker thread ❌ but the test passes ✅
- Run only that test method and no stacktrace.

So I've been pulling my hair for the last two days trying to figure out what was throwing in that test method. Turns out that thanks to the multithreading going on, some other, similar method threw the exception in parallel. And apparently a different test method was already running when the exception was finally caught.

🖕

When I discovered that, it was fixed in a minute. 😭

I am about to try TDD for embedded C. Does anyone around here tried that? What are your experiences with it? Thanks!

We rewrote the whole thing, except for iFraming some old pages in. We had to, the system was fucking awful and couldn't cope with any of the new mission critical requirements.

Client didn't understand the scope. Our project leader somehow snuck it in and we worked on it for months. We were sure we'd be kicked off the whole project... Somehow things didn't crash and burn. How it didn't blow up defies rational thought and the laws of physics. The new system worked, the client was happy, and boss made a lot of money.

Lead dev worked weekends for what feels like an eternity, it really was his baby and no one else on our company could have done it. It's where I finally learned how to do things the proper way; DDD, unit testing and TDD, architecture, building strong components in front-end, you name it. Before that I had a great nose for code smells and how not to do stuff, but now I got to see a proper system for the first time. It was glorious.

Then lead dev left and the system degraded quite a bit because new team didn't keep to the architectural patterns or general best practices. But we had a good run.

What I'm doing now, writing a JS library for a simple kitchen timer (like, something that can be wound up, is ticking, can be paused, etc). Here's a list of neat stuff I've learned:

Polyfilling as a lib author (I decided against it).
Packaging the lib (using Rollup, ES6 modules are totes cool).
Using flow to add static typing in strategic places (started appreciating types in JS since reading up on functional programming).
Modelling state and transitions using an explicit state machine. (Fucking finally. There's usually an implicit state machine somewhere, only spread out all over the app...)
Using mostly side-effect free methods, being very explicit about when and why things are mutated).
Test-first/TDD (ish) using Jest and the awesome Wallabyjs.
Freeing up mental capacity by letting Prettier format my code for me (it was hard to let go but totally worth it).
Started using git.

Did all work on Ubuntu after pretty much a lifetime of Windows (initially to separate work from gaming) and finally swapped MS Visual Studio for Atom.

When it's finished I'm going to publish it on GitHub, which will also be a first for me. Might try out some CI platform while I'm at it.

tl;dr: wrote some js, felt good

TDD: the quickest way to turn a love for coding into pure hatred.

FUUUUUCCCKKKK!!! I WASTED 2 WEEKS ON A PROJECT BECAUSE I COULDN'T GET THE RIGHT SPECS UNTIL THIS MORNING.......

I SPENT THE LAST 2 WEEKS BUILDING AND TRYING TO GET THINGS TO WORK THAT I DON'T NEED....

Tip: Write `throw new Error("problem: <your task for next Monday, and your last thoughts about that>") at the end of your test-file.
Then you come back to work after the weekend and know exactly where you left off!

Thank me later, as I thank my Friday-4pm-me

Would you like to talk about our god and saviour TDD?

P.S. I like test driven development very much. It makes complex stuff really easy.

Functional test are failing.

Expected: 7109
Got: 9000

Grep code-base for 7109. No findings. 0_o

Dig through test setup written by a drunk.

Find:

assert(actualPrice === 1800 * conversionRate)

Goddamnit. You shall not calculate your expected values in a test setup.

TDD:

it's almost done, I just have to add unit tests

My favourite type of development is BDUDD.

Blaming Dumb Users Driven Development

If you are going to tell me you develop using TDD, it's a good idea to actually have tests in your test project.

!!!rant

Most exited I've been about some code? Probably for some random "build a twitter clone with Rails" tutorial I found online.

I've been working on my CS degree for a while (theoretical CS) but I really wanted to mess with something a bit more practical. I had almost none web dev experience, since I've been programming mostly OS-related stuff till then (C). I started looking around, trying to find a stack that's easy to learn since my time was limited- I still had to finish with my degree.

I played around with many languages and frameworks for a week or two. Decided to go with Ruby/Rails and built a small twitter clone blindly following a tutorial I found online and WAS I FUCKING EXITED for my small but handmade twitter clone had come to life. Coming from a C background, Ruby was weird and felt like a toy language but I fell in love.

My excitement didn't fade. I bought some books, studied hard for about a month, learned Ruby, Rails, JavaScript, SQL (w/ pg) and some HTML/CSS. Only playing with todo apps wasn't fun. I had a project idea I believed might be somewhat successful so I started working on it.

The next few months were spent studying and working on my project. It was hard. I had no experience on any web dev technology so I had learn so many new things all at once. Picked up React, ditched it and rewrote the front end with Vue. Read about TDD, worked with PostgreSQL, Redis and a dozen third party APIs, bought a vps and deployed everything from scratch. Played it with node and some machine learning with python.

Long story short, one year and about 30 books later, my project is up and running, has about 4k active monthly users, is making a profit and is steadily growing. If everything goes well, next week I'll close a deal with a pretty big client and I CANT BE FKING HAPPIER AND MORE EXCITED :D Towards the end of the month I'll also be interviewed for a web dev position.

That stupid twitter clone tutorial made me excited enough to start messing with web technologies. Thank you stupid twitter clone tutorial, a part of my heart will be yours forever.

Failed asserting that false is true.

No shit sherlock ;/

they say do TDD

but its often that my test is wrong while my implementation is correct lol.

I really resent people who reduce the occupation to tickets. Our world is just tickets, tickets all the way down.

"well the ticket just says this, but that's vague, so what should I do?"

You either ask for clarification, or you get creative with the blank canvas you were handed.

"well that edge case wasn't called out in the ticket's specs"

this is _why_ we do TDD - to design our code to be able to function as expected for ALL cases

"is there a ticket to refactor that?"

what?! no, it's your job to always leave code better than when you found it (within scope/reason of course)

FFS we are not hired to be code monkeys or glorified typists. There should be joy that comes from getting to be more clever than the average bear and to solve problems and improve things with your code and logic.

shit bums me out.

I had mentioned before I got offered a new role, with 50% increase.

I wasn’t expecting my current employer to counter, but they suddenly shat themselves and basically matched the salary, and offered promotion to software developer (sans junior). They acknowledge my role within the company is only increasing in responsibility and so far I have exceeded expectations. Its a nice response to have from them, although I do wonder how long it might have taken without the panic.

The new company have counter-countered, promising to raise salary by a further 20% of total, within the first 6 months, provided I learn React reasonably quickly (about a month), integrate with the team and start to take on my roles within the Agile set relatively independently (3-6 months). They also don’t bother with the junior role title at these pay bandings.

I currently get about half an hour a week with my lead dev on sticking issues. In this new team, I would be one of ten javascripters, working towards best practices, TDD etc. This is absolutely the realm I want to specialise in, at the first stage of my career.

I said I would stay with my current employer, before the counter counter move. Now I am full of doubt.

Has anyone landed in teams like this, only to find they didn’t offer increased learning at all? If that was a high risk for me, I wouldnt take it, despite the offer of more cash. I’d sooner get more skilled in the stuff I have been working in at my current role.

Pretty amazing how much amazing life experiences can cause anxiety. Never been in the middle of a bidding war before...

Wrote this on another thread but wanted to do a full post on it.

What is a game?

I like to distinguish between 1. entertainment, 2. games, 3. fun.

both ideally are 'fun' (conveying a sense of immersion, flow, or pleasure).

a game is distinct (usually) from entertainment by the presence of interaction, but certain minimalists games have so little decision making, practice, or interaction-learning that in practice they're closer to entertainment.

theres also the issue of "interesting" interaction vs uninteresting ones. While in broad terms, it really comes down to the individual, in aggregate we can (usefully) say some things, by the utility, are either games or not. For example if having interaction were sufficient to make something a game, then light switches could become a game.

now supposed you added multiple switches and you had to hit a sequence to open a door. Now thats a sort of "game". So we see games are toys with goals.

Now what is a toy?

There are two varieties of toy: impromptu toys and intentional toys.

An impromptu toy is anything NOT intended primarily, by design, to induce pleasure or entertainment when interacted with. We'll call these "devices" or "toys" with a lowercase t.

"Toys", made with the intent of entertainment (primarily or secondarily) we'll label with an uppercase T.

Now whether something is used with the intent behind its own design (witness people using dildos, sex toys, as slapstick and gag items lol), or whether the designer achieves their intent with the toy or item is another matter entirely.

But what about more atmospheric games? What about idle games? Or clickers?

Take clickers. In the degenerate case of a single button and a number that increases, whats the difference between a clicker and a calculator? One is a device (calculator) turned into an impromptu toy and then a game by the user's intent and goal (larger number). The second, is a game proper, by the designers intent. In the degenerate case of a badly designed game it devolves into a really shitty calculator.

Likewise in the case of atmospheric games, in the degenerate case, they become mere cinematic entertainment with a glorified pause/play button.

Now while we could get into the definition of *play*, I'll only briefly get into it because there are a number of broad definitions. "Play" is loosely: freely structured (or structured) interaction with some sort of pleasure as either the primary or secondary object, with or without a goal, thats it. And by this definition you can play with a toy, you can play a game, you can play with a lightswitch, hell you can play with yourself.

This of course leaves out goals, the idea of "interesting decisions" or decision making, and a variety of other important elements.

But what makes a good game?

A lot of elements go into making a good game, and it's not a stretch to say that a good game is a totality of factors. At the core of all "good" games is a focus on mechanics, aesthetics, story, and technology. So we can already see that what makes a good game is less of an either-or-categorization and more like a rating or scale across categories of design elements.
Broadly, while aesthetics and atmosphere might be more important in games like Journey (2012) by Thatonegamecompany, for players of games like Rimworld the mechanics and interactions are going to be more important.

In fact going a little deeper, mechanics are usually (but not always) equivalent to interactions. And we see this dichtonomy arise when looking at games like Journey vs say, Dwarf Fortress. But, as an aside, is it possible to have atmospheric games that are also highly interactive or have a strong focus on mechanics? This is often what "realistic" (as opposed to *immersive*) games try to accomplish in design. Done poorly they instead lead to player frusteration, which depending on player type may or may not be pleasureable (witness 'hardcore' games whos difficulty and focus on do-overs is the fun the game is designed for, like roguelikes, and we'll get to that in a moment), but without the proper player base, leads to breaking player flow and immersion. One example of a badly designed game in the roguelike genre would be Early Access Stoneshard, where difficulty was more related to luck and chance than player skill or planning. A large part of this was because of a poorly designed stealth system, where picking off a single enemy alerted *all enemies* nearbye, who would then *stay* alerted until you changed maps, negating tactics that roguelike players enjoy and are used to resorting to. This is an important case worth examining because it shows how minor designer choices in mechanical design can radically alter the final quality of the game. Some games instead chose the cheaper route of managing player *perceptions* with a pregame note: Darkest Dungeons and Amnesia TDD are just two I can think of.

React.js + capybara = why the fuck i cannot click on fucking button

I found out today that productivity gains by TDD doesn't actually have any empirical backing despite numerous studies.

It now goes in the same drawer as object oriented programming.

The moment you realize that you have successfully beaten reality with your unit-tests...

There are unit-tests for ...
... the api returning a 408 Http StatusCode when an internal request times out.
... the react app take this status-code and fires an action to display a specific error message for the user.

Every bit of code runs just fine.

Deploy this hell of an app on the server. Dandy Doodle.

Do a smoketest of the new feature.
FAIL!
Chrome starts to crumble during runtime. The api Request freezes.
Firefox takes the 408 api response but fails to interpret it in react app.

So I began to wonder, what the hell is going on.

Actually I recognized that I had the glorious idea to return a clientside error code in a serverside api response.
Glorious stupidity :/

Finally I fixed the whole thingy by returning an 504 (Gateway timeout) instead of 408 (Clientside timeout)

Cheers!

Has anyone ever had the joy of dragging their employer kicking and screaming into the 20th century?

I've been here a little over a year, and slowly but surely I'm moving us forward.

We implemented git via GitLab (our it department already had an on premise installation), I've got us up and running with basic pipelines, I'm pushing TDD, im leading the move towards APIs for new development, and I'm implementing new projects to streamline our work, mainly by automating tasks which currently can take hours with hundreds of manual changes.

It's slow going, and there's lots of legacy business critical apps which we won't be able to change, but we're getting there.

If things keep going smoothly then I might even ask for a ride to reflect my benefit to the business, and extra responsibilities I've taken on which are far beyond my official job as an SQL Developer

Started my first private App project using all the goodies of 2017 android development like TDD, Android architecture components (hence MVVM), kotlin (which I yet have to learn), RxJava2 (if I need it additionally to AAC) and maybe try to set up a CI environment.

Wish me luck guys and girls 😁

Coworker pushed some changes and gave me good reason to rant.
Here's my story:
I start implementing a new feature, senior reviews it and suggest some changes, which are actually good ideas. I continue developing and implement the suggested changes.
The next day, senior keeps working on outdated source and makes similar changes like i did on the day before. Just pushes it anyway and breaks fucking everything.
The api now contains redundant information.
My classes still exist, but aren't used anymore. Let's keep some redundant code in the project, because deleting it is so much work.
All the unit tests broke, but he just commented them out, so everything is green again. We have now 0 tests which actually do something in the project, but at least the build is green...

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".

Change my mind

My boss was told that dev team cant do TDD because they are agile and following scrum. Did not know what to say.😏

Seriously, does anyone really use TDD? It sound good in theory, but generally the devs are already used to implementation-first and are not willing/disciplined enough to change their mindset.
I think the biggest disadvantage of TDD is not taking into account how freaking lazy developers are in general.
Or maybe I just wasn't willing enough to make the change.
Thoughts?

1. Learn to be meticulous.
1. Learn to anticipate and prepare a functionality up to 90% accuracy and coding it in a one shot.
1. Become advanced in SQL.
1. Increase my modularity abstraction awareness.
1. Learn to TDD properly.
1. Don‘t get angry with my kids but explain to them with papa is always right in a Calm voice.
1. Do the same for partner.
1. Train my speed running in case partner wants to bash me.
1. Become advance d in Java.
1. Learn to write a bot.
1. Learn more about servers and hack at least one thing even if its a wifi.
1. Install kali linux.
1. Make myself a custom pc.
1. Ask god (or buddha if god is too busy) to make days longer.
1. Buy a vaporiser ao i can smoke my weed without mixing it to tobacco.
1. Get my license.
1. Start investing.
1.........

When an interviewer asks, what are the steps that you take usually when given a task to do something, what do you guys say?

I said, I devote 10-20% of the time to understand the given problem - sit and explore all possible scenarios to handle, then develop a brute Force approach, improve the approach to make it more efficient, see if it handles all edge and corner cases, then write test cases for it.

( I'm thinking, the process doesn't vary a lot for most of the people?, Except in TDD - one'll write the test cases first)

How would you answer this question?

I have this feeling that I messed up something 🤔

God I'm getting tired of the whole TDD culture. I get it, testing is good, but we're getting to the point where several major OSS projects fail on common real-world use cases because instead of worrying about the main purpose of a software, devs only worry about satisfying their artificial tests. And when someone opens an issue, it just stays there for months or even years simply because setup & teardown logic for the required tests would be several times more complex than the actual fix.

Teach students the importance of clean code/architecture and testing. Even if they dont yet understand the more complex topics such as architecture, they should understand why quality is important and that software is a craft more than a science. You cant just apply principle X and insert design pattern Y and profit++. You actually have to think and constantly improve. AND TEST.
Think I would probably also cover things like build automation and continuous delivery. These are now important things for junior devs to know about going into companies.

How do you guys cope with being a junior dev and constantly receiving criticism about your work from your team leader?
I started working as a developer quite late: I did go to college in my early years but I was lazy at the time, so I didn't complete it. So I worked about ten years in a totally different industry, but I always wanted to go back to being a developer.
I've managed to do it when I was 34: I was a web developer in a small company and I was pretty much the only dev, except for an older dude who only knew Visual Basic 6 and kept programming things with it (in 2020ish!). In those years I always felt like a was way ahead of my colleague, and my efforts to apply best practices were not so welcome.
I eventually got tired of that situation, because I was feeling like wasting my time: I was already quite old and stuck in a jurassic environment
Then, I landed in a new company. Completely different environment: they use modern frameworks, TDD, static analysis, code reviews and stuff, and they do one to one meetings every two weeks. From the beginning, I felt like I was the dinosaur there: they were way ahead of me and I struggled to keep the pace. I immediately said that to my manager, but he was like "don't worry, it's just the start. I'm sure you will do great". Except I did not. I started collecting criticism about my work and I keep receiving it. When I tell my manager that constant criticism is not good for my self esteem, he replies "I can understand, but you have to manage it and I cannot avoid to correct you when you make mistakes". But it became really difficult for me to receive constant criticism, I very rarely have a compliment or a good word about what I do.
Is it just me? Should I finally grow up now that I am almost 40 and accept that working always sucks and you cannot be satisfied of what you do? Or am I simply a bad developer and should look for another job?
I am starting to get tired of this situation.

Every time I try to write a unit test I seem to write an integration test instead. 🤦
I'm just awful at it.

Always always always always always keep writing tests as you implement features. TDD is good thing but not necessary but tests are really necessary. I thought I'll write tests later now the code is so tightly coupled I can test things independently. 😑😑

Ok ok ok, I will preface this by saying I am still a student so you can assume my complete and utter lack of experience.

There is all this fuss about unit testing and TDD but i still have my doubts about it. How is it that if your code works for certain inputs you can be sure that it will work for whatever can happen after deployment?

I mean, to my understanding testing can assure that some business requirements are cared for but as far as actual code correctness goes I don't see how that is achieved.

As far as i am concerned the closest it comes to complete code correctness is a mathematical type of proof but that should be impossible to be done effectively in an OO language.

How can you be sure that your code is what you think?

(If i have this all wrong please correct me)

First time used the TDD approach. I knew I needed to use it but never quite used it cause I thought it would slow me down. I was so wrong!
Mocha and chai js rock 🤘

Non-devs will never understand the satisfaction when you see your tests run successfully on GitLab for the first time. (Last course at university and we are supposed to do TDD for the first time. )

When explaining unit testing:

"We tried but every time someone changes something in the database all the tests fail."

*facepalm*

I really wish that I adopted TDD earlier

Who else works at a company that enforces test driven development? And after doing TDD do you think you could ever go back to NOT doing TDD?

When you're writing unit tests TDD style and you realise how close your deadline is:

Hm... Apparently I've been doing TDD all along... it's just that I don't save the tests in a seperate project.

I just keep editing Main() to test whatever i'm working on (each class).

Also the NJTransit site is sneaky as ****. It seems the devs know a bit about how to prevent site scraping by checking Headers and Client information...

Took all afternoon to get this test to pass....

it works in Chrome but not in my code... and even after I spoofed all the headers... including GZIP.... it wouldn't work for multiple requests...

I need to create a new WebClient for each request.... no idea how it knows the difference or why it cares... maybe it's a WebClient bug...

And this is only the test app. Originally was supposed to be built in React Native but that has it's own problems...

Books are too old, the examples don't work with the latest...

But I guess this also has a upside... learn TDD and React rather than just React... hopefully can finish this week...

I'm actually on vacation... yea... i still code like a work day... 10AM - 8PM....

Whenever i get bored at work i try to motivate myself, because i notice that as soon as i am less interested, i loose focus and make mistakes.

Therefore i try to keep motivation up. One thing that helps is actually TDD, because you are able to have several small subgoals, which each leave you with a feeling of achievement, when a test you wrote passed, kinda like achievements in games.

When the task itself is so boring that even TDD doesn‘t help, i try to have fun while painfully working through it. Like have a coffee break every now and then or rant with a coworker about the task.

One time a coworker and me had to create a demo in Unity and we hated the task, because it was exactly this brainless and cumbersome clicking in the Unity3D UI which felt awful to us (we are embedded developers and we find comfort in the terminal 😄)
The only thing that got us through the task was ranting at Unity and periodically goofing around in the engine and adding weird behavior to objects.

Omg nothing is as frustrating as writing tests for a given file, that is needed to achieve 100% code coverage. Also not following TDD.

I recently started to use automated tests for everything and it is really great to not worry about every little change anymore.
But I think I'm not very good at it. The tests themselves are quite slow and I'm not sure if I'm covering everything the right way. Also, I'm very slow at writing the test cases.
SO I want to learn more about it. Do you have any recommended books on this topic? Anything about unit or feature tests and TDD, language specific (PHP) or general is appreciated

If this unit test were a real person, I'dsmack it across the face with a steel pipe and shatter its spine with a spiked mace coated in acid. Then I'd toss the fucker into a pit full of a hundred angry, rabid weasels and snarling, hungry raccoons, sprinkle some ground chestnuts and cocaine and tell bastard to run until I see some goddamn green.

When you tell one of your teammates this would be a perfect feature to develop using TDD. They agree, and after a couple of days they send you a code review with 0 unit tests and a message saying "I will start working on the tests while you review this."

So, i started TDD with ruby today. And i got to say, RSPEC IS SO FUCKING COOL

You know you're a glass is half empty person when you test the negative case first.

Best productivity hack...? Spend the final 30-45 minutes of the day writing failing tests. Once you get in the next morning you'll have an instant challenge to get you straight into the zone, and a documented reminder of where you left off. (tdd purists need not apply 😝)

I feel like some developers focus too much on concepts like clean code, software craftsmanship, TDD and so forth, to a point where they almost forget end user needs (ease of use, intuitive experiences, general UX principles).
Don’t get me wrong. I do my best to stick to a decent standard of quality and maintainability. However my solutions are adapted to the specific needs that are being addressed rather than the other way around.
I’ve heard some devs say things to the effect of ”well I know that’s not most intuitive behavior for the user but it’s the cleaner way to do it, so the user will just have to figure it out“. So in essence they’re just coding for their own pleasure rather than addressing user needs

Just attended a code Dojo meetup by software craftsmanship peoples - a lot of fun!

do you use TDD with PHP?

When I started developing my current Django project, I had decided to go full TDD, do it like a pro. But I stopped after some time, as I spent more time trying to make the website look right than trying to make the backend work, which always seems to work fine. Am I an idiot? I think I'm going to regret it...

Tdd isn't very effective if the spec keeps change as you work.

I was trying to be good and write tests as I went, but it just ended up taking twice as long since I had to keep rewriting the code AND the tests.

And here I am again, reading test cases that basically boil down to:

$testCase->foo = "bar";
$this->assertEquals($testCase, "bar");

$testCase2->foo = null;
$this->assertNull($testCase2->foo);

Why would anyone feel the need to write these kind of tests? They don't do anything. If I set up my mock a certain way, of course I will have that data, esp. if the unit under test only applies the data AS IS. (Funily enough through another component that already has the relevant dummy tests in place making these tests extra redundant and obsolete.)

You would think that one test case with dummy data suffices, yet no, there are like 30 examples that lie to you about apparent business logic cases, yet in the end the way you set up the mock decides what you will or won't get.

What's the point?

Due to sad circumstances at my current company, I had to work with bash scripting exclusively.

At least I found joy even in this situation and now I'm satisfied with my bash TDD practices...

¯\_(ツ)_/¯

I just reviewed a pull request with a test case like (pseudo code):

# Test MyService

const mock = createMock(myService.myMethod)
.whenCalledWith("foo")
.returns("bar");
assert(mock.myMethod("foo") === "bar"));

Why though? Why are we testing the mock? What is happening here? This test has no reason of being there instead of a fuzzy feeling that we now have unit test to lure us into a false sense of security.

I asked why we don't do an integration test. Response was: "They are slow."

Well, duh, but at least they would actually test something.

What do you gain by asserting that the mock is working the way you set it up?

Colleague wrote all his test cases after finishing his code and set expectedOutput to garbage. His tests failed, printing actualOutput. Then he just replaced the garbage expectedOutput with actualOutput. Bingo bango, all tests passed.

"How do you like me now TDD?"

Friday wisdom.

Software is not written. It is rewritten.

After spending 3 days approx. On thinking over a design problem. The first 2 days I was clueless how the problem is going ahead. Today I deleted all classes started again and voila.!! It works like magic and I did it with a TDD approach so got good test coverages too.

P.S. I didn't come up with that line. I got it from a tech talk and now understood it's meaning.

I wish we could stop to push candidates to do TDD or even asking questions about it during interview. This thing is a lie, has always been and will ever be. It is cool for small coding exercises but nothing else.
Let’s stop gatekeeping with stupid concepts.

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?