Guys...

It has come this far...

I... I like test driven development and the amount of unit tests and security it gives you. And I kinda laugh at people that don't take unit testing seriously :p

Do you get a boner thinking about how other people don’t write tests and therefore are losers?

And here i am not writing unit tests and feeling guilty about it.

@grumpyoldaf Only when they're actively struggling with breaking refactorings etc.

I am too lazy to write unit tests and refactor sometimes but I totally agree.

@jennytengsonM give him/her a graph showing why writing tests is good for the future and that it ensures a more stable development time rather than an increasing amount of time for each new feature

@jennytengsonM "just like code comes with letters and numbers, it comes with tests. If you need me to drop tests it will take me 3x-4x slower, since tests is how prod code is built. Nevertheless I will not be building the app w/o tests - I am not willing to start writing horrible code and add that stain in my professional career history just because you ask me to. I am the developer, not you, hence I should not be explaining myself how I do my job. Take it or leave it."

grow a backbone allright. You are the fucking engineer, not some minion.

@jennytengsonM very well.
I appoligise, I immediatelly assumed you've said YES OFC to that. Since most of the people around me are like that..

@netikras lolololol. Tests is how prod code is built? Are you a fucking child?

I understand TDD has its place and it’s advantages but y’all need to stop sucking it’s dick like y’all are thirsty.

@grumpyoldaf there is no need to exhibit the fact that you are stuck in between phalic and oral development phases just to say 'I have a different mindset than yours'.

I always build prod code with tdd now. Haven't come across a case where this method would be less suitable, or unsuitable at all for the matter. Have you?

@netikras The irony on your first paragraph is thiccccc.

Yes. Extremely tight deadlines and industry specific situations. Code that you have to write for systems where the business has halted operations so you can get your application up with a feature that’s needed immediately. Financial industry is chock full of cases where you have to write a piece of functionality in a couple days and make it work. The testing as it is by QA is extremely thin. Medical equipment interfaces on the application side that need to be fixed or tinkered with and deployed as soon as possible. You simply don’t have the luxury of time on your side to even think about tests in so many cases. Stop preaching TDD everywhere for fucks sake.

I am in team that is making react app, from the first day i tried to establish that we should do it react way, best practices, i prepared TSlint and stuff and really looking forward to write styled components. Asked about tests - nope nadda.So i prepared some components and presented way we should work on it. Great, high quality code, but... Lot of corporate ideas, tons of documentation to write first, regarding the code - several different patterns introduced at the same time from different team members, files full of linter ignore comments, everything is 'any', git is a guitar hero mess, had case for generics and started writing it but no no generics, just put 'any'... And then... Guys we should write tests. Stop everything you are doing and write tests. What a mess!

Sometimes i wish i dig holes for life!

@grumpyoldaf see? This attitude right there is the problem. Such attitude makes us look like minions. Those yellow ones who do as they are told for a bannana or less.

And imo you are wrong. You have all the time you need to do it right. PMs, POs, HODs, marketing folks and others are the ones who have tight deadlines, because they have oversold. Business has the urgency - not you, the technician. And business applies pressure on techies, because: a) if they deliver the project on time they pop a champagne get a fine bonus, b) they can show that they can deliver faster, ergo they show progress, ergo - raises.

But do THEY deliver? Frankly I have not seen a single manager creating the product. Have not seen marketing folks doing commits. Have you?

They do not deliver my friend. You do, the tech person. What they do - they orchestrate the delivery, make [rarely] informed decisions and manage risks. That's not all. They also apply pressure on you to make things happen faster. So the company, department or the sales dpt would look better. So that they would move up in the world by making our lives miserable.

This is how we've become the true blue collars. Plumbers of the IT world. Even though we are highly intelligent engineers, builders, creators, designers, architects,... By agreeing to bend and pass soap each time mgmt/business needs smth quickly we've demoted ourselves to the level of plumbers. And that, my friend, is why I do not agree with you.

Now ask yourself: does a plumber agree to install all the pipeline in 3 hours in a 12 stores office just because business asks to?
Does a construction company agree to building a skyscaper in a week because finances' business needs it right away?

Tge fact that we are fanatics of what we do and the need to be recognized, the fact that we start coding as kids, mindset lije yours and lack of a backbone made technicians into it plumbers. And maybe even worse.. Minions.

@grumpyoldaf I've worked in many, oh so many blue collar pisitions besides IT. And nowhere, NOWHERE were we treated as minions, as property, assets, like we are in tech. Most techies are too soft and agree to everything they are asked for, no matter how stupid or insecure and far from industry standards it is.

Cheff, lawn mower, operating room assistant, nurse, waiter, construction worker, helping hands in concerts and many more. Everywhere I was respected more and my word had more power than in it. I'm trying yo change this, at least around me. Have a few folks thinking the same around me. I see some progress but each time someone like you comes and opens their mouths all the change rolls back immediatelly.

@grumpyoldaf my point is we should stand our ground. Disagree with estimates made by others if we cannot deliver them the right way. We are the people who know. We are the people who do. We are the ONLY people in the world competent to make estimates and not flexing when we are asked to do the impossible or do it the way they, non-techies, want it done.

Or even better - be sales people selling our product - code. Making estimates fit for bargoning - doing exactly the thing business is doing with us. But thats a bit advanced. So let's do it one step at a time

@grumpyoldaf
> other people don’t write tests and therefore are losers?

From a conference a while ago: "A software system can best be designed if the testing is interlaced with the designing instead of being used after the design"

That's from the NATO Software Engineering Conference of 1968 (https://dl.acm.org/citation.cfm/...). 51 years ago, testing was not news. It was the current state of the art.

People who don't write tests aren't necessarily losers. But working like it's the fifties, boy are they behind the times.

@grumpyoldaf
> Medical equipment interfaces on the application side that need to be fixed or tinkered with and deployed as soon as possible.

The medical sector is the absolute last place I want untested, rushed tinker-code running. Say hello to cases like the Therac-25. Which products are developed like that? I need to avoid them.

> You simply don’t have the luxury of time on your side to even think about tests in so many cases.

No, you don't have the luxury of *not* testing, even more so when time is short. I know that sounds like a paradox, because testing feels like an extra that "takes time": Twice the code, work and time. In my experience that feeling is misleading. And again, that isn't news since around 1968.

@netikras tdd is a bit of a loose term at this point so i want to find out what do you mean by tdd.

when it was proposed by kent beck, the first stage of tdd is writing a test that fails first (even when there's no actual code) and then writing the code that makes the test succeed.

i kind of hate that because the way the code is structured usually depends ultimately on limitations from other software that you depend on.

i do a more lax tdd in the sense that after writing every function, immediately after i write tests for said function.

@jesustricks No, I mean the actual tdd. Writing a failing test first, making it pass, refactoring if needed, going to the next test.

In fact I've noticed my code is much more flexible when written with TDD. What TDD does it FORCES me to write flexible code.

When you are writing production code the usual way (prod code first), you are dedicating that code to production domain. And if (a big if) you decide to write a set of UTests for that piece of code, you adapt your tests to fit your prod snippet.

But that is a problem. You are adapting tests to match prod code. See, your test methods for that snippet will probably never change. You do not need your tests to be flexible, to be able to adapt to prod. You write a test and it's done. In fact you need prod code to be flexible, i.e. be able to adapt to your tests. That way your prod code will be able to adapt to new modules, new extensions and so on.

That being said, tests - first. It's tedious sometimes, but it really works well.

@netikras yeah, I fully oppose to that, I think it's esoterism.

i like the aspect of "test first" ONLY for testing compliance of code with expected behaviour,

but i don't pick my testing methodology with the purpose of improving my code

i'd like to think that i can write well structured code on my own merit.

but in fact, while i don't do traditional tdd, i think it still helps me to rethink of code and get to better designs.

i would argue that code that gets written in traditional tdd ends up being an abstraction mess with long stack traces, (function a calls function b, all the way to function z)
i like relatively flat stack straces as long as code files are small.

i don't run into any of the tediousness you mention or take too long to write tests also.

if traditional tdd gets sold as THE way of testing, then I hate it too because it scares away possible users of more pragmatic ways of testing.

i don't write too many integration tests as much as i should though

@netikras i can't really prove that traditional tdd is bad, but at least i can show what i mean with "pragmatic tdd".

this is a validation js lib i wrote with 96% code coverage
https://github.com/zzyyxxww/abides/...

I love that a rant sparked a discussion like this

@jesustricks boy am I unfamiliar with js testing... 😁

can I do

abides(myVar, ofType(null));

with this?

Or pas a null or undef as a second param? Or an array of undeffs/nulls? Or an empty array? Or an array with empty or my custom objects? And what if I pass just my custom object as a 2nd param?

Can I pass an array as a first param? An Object?

I could go on. Since js does not enforce types and has both null and undef the list of cases could go on and on.

I know there's docs. But I don't see tests for wrong cases... And a test suite should be as good as a doc imo :)
you don't need to write a test case for each case. Just have them covered by some conditions grouping cases I've mentioned.

these are trivial cases, I know. But you are doomed to miss them if you are thinking the usual prodCode-and-then-tests way. Because you are concerned to only prove your prod code does what it does. You no longer care to see "what happens when..." :) you are too tempted to do shortcuts to just win coverage.

@alexbrooklyn indeed. It's a shame it [almost] ended so quickly :/

@netikras I should have handled bad user inputs. I didn't do that because I wasn't sure *where* should I do that.

In fact, at some point of the project I had type checks on *every* function of the project, and the accompanying tests that passed bad values to them (here's proof https://devrant.com/rants/2266655/).
(continues...)

Eventually I removed them because it was trying to make js something it's not. But now that time has passed and mind is fresh, I know a couple of places where there should the type checks be, some almost-top-level functions.
(continues)

@netikras I am against "prodCode-and-then-tests" too, so let me rephrase what I'm doing in case to clarify:

For every new function that I write, even in a start of project stage, immediately after I write a test for that function.

Also, like traditional TDD, when I discover bad behaviour later on, I write a test that shows that, and then fix the code.

So it's still a very sensible approach, and unlike tdd, it doesn't put handcuffs on your hands like "you can't write code before tests, you bad boy".

Sometimes you need to write code and explore what some external API does to even decide if you care about writing tests for it.

Sometimes you have absolutely no idea what you should test, because APIs sometimes depend on implementation that you're going to pick.

I think traditional TDD kills developer freedom of experimentation and prototyping. And time also.

I'd rather have 90% code coverage through pragmatic testing than 101% code coverage through time killing traditional tdd

Count me in as someone you can laugh at. Your day will be brighter for it, and my day will continue to be better because I'm not writing unit tests.

I understand users expressing the difficulty for not writing integration tests, because they are hard to write and setup.

But being proud of not writing unit tests is not just irresponsible but also insanely stupid for basic reasons, like wasting fucking time.

"Look at these silly idiots with their rounded wheels"

I enjoy not having to run things manually a hundred goddamn fucking times, except some special cases that require that. For the most part though, tests save me a lot of grunt work, like manual execution.

If you like wasting time, sure, write no tests at all.

@jesustricks I agree about experimentation. Dunno about prototyping. But I disagree about time :)
well at least in a long run.

And I find it much easier to make decisions and the overall design with tdd. Whenever I need to implement smth I no longer have to waste time on trial-and-error which usually ends up with hacky solutions in the end. I simply write a given-when-then method name, write the 3 parts of the test and implement.

I no longer operate in assumptions and trial-errors. I just write down what is it I want to achieve and just implement it. One thing at a time.

I no longer write code by experimentation. I just write it to simply match certain criteria I set to myself beforehand :)

writing prod code first and then covering it with tests [doesn't matter whether immediatelly or not] is no longer working for me :) it makes me go sloppy compared to test-first.

@jesustricks the twist [and the hardest part] in switching to tdd was changing my mindset. I usedbto write code before. Now I write solutions to problems. I used to operate in services, think which services I need to pull to which other services and what function to write, what params, etc, etc. You know.. The stuff developers love about coding :)
now I can literally open up a BA's confluence page, take all the bullet points and transform them into test method names and write tests asduring that each and every use-case of the sw is working and at any given time I know what the app will do with given data. But all thatbis given that we already have the code..

Now imagine a brand new feature requirement has just come in. What do you do? Idk frankly 😁 but I assume you go straightbto the peod code, write some functions, add some dependencies, cover your fubctions with uTests. What I do is write each use-case of the feature down as a test case and implement them one-by-one. Switching my thinking from code-first to test [or a 'use_case first'] was the hardest part for me.

There are many reasons to write unit testing and many reasons not to. I don't understand this fanaticism around it.
If you work on a small code base.
If you are a single dev in a strongly typed language. (small mid size codebase)
If you write a single use program.
If you work on embedded chips. (there is testing, but those are not unit tests)
You don't need it.
If you want to collaborate you kinda must use it.
If there is shitton of code to support you kinda must use it.
If you want a live showcase/documentation on how to use your code you kinda must use it (Prolly integration tests are enough)

The TDD mentality also have pros and cons.
Pros you do not need to have high-discipline to finish working on a task (writing tests is the most boring thing one has to do imo)
Cons, it does often force an overly high reliance on the testing system (you already have ultra high coverage), which in turn introduces code duplication

Something many people forget (without commenting on the advisability of tests for any specific scenario) is that tests are not your product.

@monkeyboy tests aren't the product in the same sense bad code isn't the product

@monkeyboy they are a part of it

Are you guys 100% for the tests, i mean using tests on absolutely every project?

I am for writing tests for the apps where you have some logic, but for simple websites (ie small Gatsby projects, using mostly promise on request/markdown or graphQL for data and mapping all the things around) IMHO tests are ok, but not really necessary.