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

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.

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

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.

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

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.

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.

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

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

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.

When you learn to write tests..

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

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

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

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*

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

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?

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

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!

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.

I love TDD.

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

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.

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

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

> 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? :)

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

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

I wish I could do TDD on my life decisions

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

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

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.

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

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

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!

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.

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.

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"

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

finally someone said it

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

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

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.

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.

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

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

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!

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

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

#clowndrivendevelopment

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.

unit testing

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

I tripped too🤦‍♂️

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.

Developing in TDD.

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

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?)

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

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

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?

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.

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!

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.

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 !

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

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

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

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 :)

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

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

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.

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.

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

Impossible changes become possible.

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!

Roger that!

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

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

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

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

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

My favourite type of development is BDUDD.

Blaming Dumb Users Driven Development

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.

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:

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

they say do TDD

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

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.

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?

!!!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 ;/