Do you follow test driven development?

Classes are classist.

Objects are objectifying.

Race conditions are racist.

Foreign keys are xenophobic.

Functions are ableist.

Thin clients are weightist.

Bitmasks perpetuate heteronormativity.

Code beautifiers promote unrealistic beauty expectations.

Test-driven development is victim blaming.

Forced commit pushes are rape.

Motherboards perpetuate gender roles.

And don't get me started on white space.

Looks like I'm getting fired on Wednesday :)

Long story:

*I add first unit tests to project.

*Boss adds new functionality and breaks all the tests so I can't compile and write more for what I'm working on.

*Boss is very fragile and cannot handle any comment that can possibly be taken as a slight against him.

Me: "I wanted to ask what our policy on unit tests is please? Because we haven't really said how we are treating unit tests, and everyone myself included is not thinking about them. I also haven't added tests when I fixed bugs and this time your changes broke the tests"

Boss 10 minutes later: "I want to speak to you in private".

Boss: "you are too forceful and direct. You said I should have added tests."

Me: "yeah but I didn't mean in a nasty way"

Boss getting louder and more aggressive: "You are too forceful"

Me: "I didn't mean it in a bad way"

Boss: "I didn't want to add tests for that!"

Me: "then why add any tests?"

Boss: "Fine we are not having this conversation now!"

*Boss storms out

I decided I can't speak to the guy about anything without upsetting him spoke to the manager before I quit because I can't work like this.

That resulted in a meeting with my boss, his boss and the head of HR where I ended up savaging him and told them I can't bring up anything as I can never tell if it will offend him and that I spend ages writing emails and trying to document communications because I just can never tell if I will upset him. Also that I cannot bring up any ideas because I can't tell if he will somehow get offended and that I can't even write code because if I change something he wrote at some point he will get angry.

My boss claims that I am extremely forceful and disrespectful and that I am constantly insulting him and his decisions.

We go back over a ton of shit and I refute everything he says. In the end I have to have a meeting with him on Wednesday where we either get things straight, he fires me or I quit.

I think at this point that our relationship is too fucked for him to be my team lead on a 6 man team.

Side note I keep bringing forth ideas because we have one database shared between 6 Devs, no pull requests (apart from mine and another new guy), no test driven development, no backlog, no team driven story pointing, no running tests before merging, no continuous integration setup, no integration tests, no build step on merge, no idea of if we are on track to our deadline other than his gut feeling, no actual unit tests backend - just integration with a test db, no enthusiasm to learn in the team and no hope.

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.

"Can you work on this ticket? It's kind of urgent."

-- "OK"

"And could you please not refactor? Just get this done."

-- "Why? What's the issue?"

"The logic is complex. We should not break it."

-- "Erm, that's what the tests are for. So yes, if the need arises, I'll refactor. The tests are my guidelines if the logic breaks or not."

There's a reason we create tests. So let's not hinder code base improvements by some random fear that stuff might break.

If breaks due to refactoring, we'll fix it by adding a valid test case during and then fixing the bug.

If my refactoring does not break the tests, I'll assume the code base is stable.

If your code is untested, then we have a complete different problem.

Let the student use their own laptops. Even buy them one instead of having computers on site that no one uses for coding but only for some multiple choice tests and to browse Facebook.

Teach them 10 finger typing. (Don't be too strict and allow for personal preferences.)

Teach them text navigation and editing shortcuts. They should be able to scroll per page, jump to the beginning or end of the line or jump word by word. (I am not talking vi bindings or emacs magic.) And no, key repeat is an antifeature.

Teach them VCS before their first group assignment. Let's be honest, VCS means git nowadays. Yet teach them git != GitHub.

Teach git through the command line. They are allowed to use a gui once they aren't afraid to resolve a merge conflict or to rebase their feature branch against master. Just committing and pushing is not enough.

Teach them test-driven development ASAP. You can even give them assignments with a codebase of failing tests and their job is to make them pass in the beginning. Later require them to write tests themselves.

Don't teach the language, teach concepts. (No, if else and for loops aren't concepts you god-damn amateur! That's just syntax!)

When teaching object oriented programming, I'd smack you if do inane examples with vehicles, cars, bikes and a Mercedes Benz. Or animal, cat and dog for that matter. (I came from a self-taught imperative background. Those examples obfuscate more than they help.) Also, inheritance is overrated in oop teachings.

Functional programming concepts should be taught earlier as its concepts of avoiding side effects and pure functions can benefit even oop code bases. (Also great way to introduce testing, as pure functions take certain inputs and produce one output.)

Focus on one language in the beginning, it need not be Java, but don't confuse students with Java, Python and Ruby in their first year. (Bonus point if the language supports both oop and functional programming.)

And for the love of gawd: let them have a strictly typed language. Why would you teach with JavaScript!?

Use industry standards. Notepad, atom and eclipse might be open source and free; yet JetBrains community editions still best them.

For grades, don't your dare demand for them to write code on paper. (Pseudocode is fine.)

Don't let your students play compiler in their heads. It's not their job to know exactly what exception will be thrown by your contrived example. That's the compilers job to complain about. Rather teach them how to find solutions to these errors.

Teach them advanced google searches.

Teach them how to write a issue for a library on GitHub and similar sites.

Teach them how to ask a good stackoverflow question :>

No matter how much product owners claim "bugs have priority over anything else", "we value high quality structured code", and "we do test driven development"...

...Once a big client wants a feature to be developed before they sign up, dirty code will be written from napkin specs, and that code will always be refractored "soon".

There are many ways of development...
Test Driven Development.
Behaviour Driven Development.
Acceptance-Test Driven Development.
YOLO Driven Development.

But nothing in this world is so frustrating as...
Buzzword Driven Development.

As soon as your managers spot a new technology, it needs to be integrated...
For fucks sake... New is not always better.

Friend of mine: so I wonder how do you test your applications in the startup?

Me: testing? *grabs his coffee laughing*

Actually we have a complete build pipeline from commit/pull-request to dev and production environments. No tests. Really. We are in rapid product development / research state.

We change technologies and approaches like our underwear (and yeah, this is frequently). If we settled some day and understood the basic problems of the whole feature palette, we'll talk about tests again.

finally started test driven development

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

A Tale of Two Codebases

"It was the best of compile times,
it was the worst of compile times,
it was the age of test-driven development,
it was the age of Stackoverflow copypasta,
it was the epoch of epics,
it was the epoch of blank bug reports,
it was the season of nginx,
it was the season of IE9 support,
it was the spring of Jenkins test jobs,
it was the winter of deleted containers,
we had our sprints before us,
we had no roadmap,
we were all committing directly to master,
we were all reverting and cherry picking,
we were all going the other way..."

Fucking non technical managers and their shitty clients to whom they suck their tiny weiners need to realise that I cannot reorder elements every 10 minutes to the shape of their fart comming out of their ass, test it, deploy it, trigger webhook, clear cloudflare cache, and meanwhile be sure that it's written in quality manner for future upkeep with commits that have sense.Hope deadline driven development dies in hell where it belongs

Apparently the fire hose in our building wasn't connected to the water main, because the legislation stated the building owner had to install a fire hose, not connect a fire hose to the water main.

Test-driven development

I love when you work up the courage to try test driven development. Then the test build fails with 20 errors....

I'll just debug it instead

BI guys ask us to avoid deploy on Fridays cause they don't have time to fix their stuff.

"We cannot test until it is live..." They said.

I hate guys who prefer production driven development.

So I started working at a large, multi billion dollar healthcare company here in the US, time for round 2,(previously I wasn't a dev or in IT at all). We have the shittiest codebase I have ever laid eyes on, and its all recent! It's like all these contractors only know the basics of programming(i'm talking intro to programming college level). You would think that they would start using test driven development by now, since every deployment they fix 1 thing and break 30 more. Then we have to wait 3 months for a new fix, and repeat the cycle, when the code is being used to process and pay healthcare claims.

Then some of my coworkers seem to have decided to treat me like I'm stupid, just because I can't understand a single fucking word what they're saying. I have hearing loss, and your mumbling and quiet tone on top of your think accent while you stop annunciated your words is quite fucking hard to understand. Now I know english isn't your first language and its difficult, I know, mine is Spanish. But for the love of god learn to speak the fuck up, and also learn to write actual SQL scripts and not be a fucking script kiddie you fucking amateur. The business is telling you your data is wrong because you're trying to find data that exists is complex and your simple select * from table where you='amateur with "10years" experience in SQL' ain't going to fucking cut it. Learn to solve problems and think analytically instead of copy fucking pasta.

I really need to get out of this clusterfuck of a mess I got into, A.K.A. our website projects. Now, it feels more and more like all these problems and issues we're having are all my fault.

Here's the thing: I had 0 experience on web development before I got this job. I started as an intern, expecting to learn all the right practices and techniques on building websites. Nope. What happened was I was thrown in this big project, responsible for almost every functionality that it was supposed to have.

A junior-level guy. Doing a huge project on his own. Hell, I'm probably even lower than a junior. But here I am, pigeonholed in this shittard. My boss even said to me, "you know more about the website than I do." Fucking hell. He's not even aware of the clusterfucks I've done on the codebase because, fuck, what did I know? I don't even get feedbacks about my code. I don't fucking know if I'm doing all of these shit right. I don't know if this function is supposed to be here, or if it's supposed to behave that way, and, shit, the concept of test-driven development is probably something my boss has never heard of before.

So right now, I'm a bit obsessed with web development best practices, and how to write clean, maintainable code. I would probably get more learning from going to meetups than I will ever have from this place.

This has been a very shitty start of my career. I hope a much better learning experience will be plentiful at my next job (if anyone's willing to hire me). It would be like starting all over again. Sorry for the long post. I would like to put this as a blog post, but it's probably not a good idea, specially since I'm looking for a new job. Thank God for devRant.

So much has happened, I've been learning things, I got robbed, I discovered I love test driven development, my laptop fell downstairs and is now screenless, I'm still on this project and still have not gotten the source or gone live, side work exists though so I get to make some more money, car engine needs to be overhauled, project extended still not in production. Send Help.

Trying to convince the class that test-driven development + DTSTTMPW ("do the simplest thing that might possibly work") + pair programming is the way to go, our software dev prof had us split in groups of two that would each get a turn to
1. add a unit test
2. edit the code so it passes the test
3. commit the change

The goal was to write a java class that converts integers to roman numerals.
Each group had only 2 minutes before the prof made them revert their changes.
After 45 minutes the code was just 10 lines of this:
if ( n == 1 )
return "I";
else if ( n == 2 )
return "II";
else if ( n == 3 ) ...

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?

Test Driven Development, Pattern Driven Development, Domain Driven Development, Design Domain Driven Development.

When do we eventually get to the development part??

2nd week at my first job after I got my papers and what am I doing?

Background:
I followed a course of three years where all we learnt was web development with php and javascript. I of course wanted more and spend hours after school learning as much as a could without any help from others.

About the course:
We learn to tinker with code (php, javascript).
There was never a mention of design patterns.
We never got to know about TDD (test driven development).

Now:
Got the papers, found a job as a c# junior development and am currently working on a C# .NET web app using azure cloud and high standards using unit tests to provide a product for the awesome company I work at which should generate a stable income.

Tldr;
Hard work pays off.

Anyone got tips on big TDD unit test assertions?

I've a private project where I am parsing code. For this my unit tests sometimes gets abnormally long, and when I have a lot of nested objects it gets tricky to keep track of what's happening in the unit test around all the assertions.

I've attached a screenshot of my currently longest unit test (in code rows) for reference, where I'm currently at a brick wall and can't figure out how to make it easier to read.

Anyone with TDD experience who could tell me maybe how this is usually handled professionally? Or just your personal best-practices on the topic?

: How can I make the tests more readable? And is that even a priority?

I've only read like first 100 pages of a book that covered TDD. I'm quite the noob in this subject, any tips are welcome!

Picked up the latest version of Test Driven Development work Python. Haven't done much test driven development so time to change that .

Best thing about being a dev? Getting that precious green bar during test-driven development!

!rant

I would like to pick up some Test Driven Development practices. So that the most people benefit: "What book/material would you suggest for each language?"

So that I also benefit: I was hoping to find some books on C#, but some of the reviews gave me doubts.

That feeling you get when starting a new scala project. Fresh start! Lessons I have learned:
1) Add a linting tool before the code gets inconsistent to the point where it has thousands of style errors.
2) use test driven development from the start so that refactoring later is a breeze.
3) Write top down, no matter how much I want to implement the algorithms first.
4) write the tests first!