My CTO everyone:

"You don't have to assert proper permissions in the backend for this user role, they won't guess the URL anyway. just hide the links"

Yikes.. fml.

Do devs really fight or do we just mildly assert differing opinions then ignore each other for extended periods of time?

Why... why the fuck do people write unit tests and then comment out the god damn fucking assertion lines....
Like what the flying fuck? Cool, we can get some code coverage marks but for fuck sake actually let your tests do their fucking job!!!

Oh, the asserts fail?
Well fucking sort that shit out instead of commenting them out.

I don't get it, if you're going to write tests, fucking test something with them, or we'd be better of without them.

Telling the boss i'm not writing bullshit assert true test cases because i have ethics

Let an expert consultant write your code, they say. It will be all right, they say.

Found this today in a legacy codebase.

Two places: At a major NYC firm, I was in charge of social media. I was also involved with an intranet community. Something went bad with the intranet community project politics and I got blamed for it even though I had emails to prove I hadn't said/done what I was accused of. But to assert their dominance, my bosses called me to their office, sat me in literally a corner of the room, and interrogated me for 2 hours. The only thing missing was the bright light in my eyes and the "good cop" part of the routine. I'm ashamed to say they "broke" me and I just gave up and did what they told me to do to "fix" it even though I hadn't done anything wrong. The bosses were old enough to be my parents, so I wonder how much of that worked its way into the psychology of it all.

The second toxic workplace was where each month the boss would come from his home by the beach to tell us plebes what new ideas he wanted us to work on. We would just get done reporting on the results of his delusions of grandeur from the month prior and he'd pull the rug out and start us on some new thing. Never got any consistent traction on anything. He was the ultimate seagull manager: fly in, make a lot of noise, poop all over everything, and leave us cleaning up the mess. Oh, and we had to change the locks because we had to fire a customer service guy who was a little bit on the ragey side of things. Because of high turnover, I had seniority within 4 months of starting there.

Has anyone felt the astonishing effect that is writing a whole bunch of test classes, hitting run for the first time and they all pass.

I'm kinda sitting here staring at my screen in disbelief, either these tests all passed, or I've really missed something and they passed anyway, or it's just a lying piece of shit trying to question my own abilities... all are possible right now.

And no, they are not " assert(1,1) "

* Ctrl+Shift+F to find all "assert" in solution...

Matching lines: 0 Matching files: 0 Total files searched: 1504

* Bang head on table

* Flip Table

* Start writing unit tests

#You never know the sun will rise. I recommend this code style.

a = 2
b = 2
c = a + b
assert a is 2 and b is 2
assert 2 + 2 is 4
assert a + b is c
assert c is 4

Don't you love having a colleague who is your lead developer and does absolutely nothing all day, looks at online deals 80% of the day and when you spend half an hour amending a friend's wordpress website, decides to tell you off and that you're taking the piss because you spent half an hour doing something other than work... Cheers pal, why don't you get off the deal websites and do some actual work instead of trying to assert power which you clearly aren't qualified for.
Regards.

I am working on an open source game project, and the most common way to draw things is using a class named ManagedSurface. The class is otherwise awesome, but it has a method called getBasePtr(x, y), which gives you a pointer to the requested coordinates. Fair enough (this is C++ without STL by the way).

But WHY THE HELL CAN I REQUEST ANY POINTER THAT I WANT, EVEN IF IT'S OUTSIDE THE SURFACE? Other cointainers have sanity checks, asserts and such, and the surface KEEPS TRACK OF IT'S WIDTH AND HEIGHT.

WAS IT SO FUCKING HARD TO ADD assert(x <= w); assert(y <= h);???

I spent 3 days on valgrind trying to find a heap corruption that manifested at random points in the code.

FUUUUCK!

On the bright side, I learned how to use valgrind (which is awesomely awesome).

Sometimes it's better to burn a bridge so you don't even think about crossing it in the future.

See, I left a company some years ago because I didn't see my future in it and all management combined had a collective intelligence of a chicken.
However, I got a call from them a couple of months ago asking me if I could return. The salary was double and the working arrangement seemed fine. On paper. WFH. Flexibile hours...
Since I actually liked the project itself for its technical challenge, I accepted the return offer. What a bad idea that was.

Of course, the things that made me leave for the first time had only gotten worse. Bad leadership, idiot developers in team leader positions. Tech debt higher than Mount Everest. Bad infra that makes you want to off yourself every time you work on it. The whole circus.
Seriously, the "senior" team leader will happily merge code that includes assert(true == true), but hold up a well written MR because he has a personal vendetta with the developer.
Personally, I always check him whenever he starts being an ass. But the poor juniors are in hell. They're terrified.
Now I'm leaving again, but this time I've made sure I can't come back.

The colleagues who do testing in my department collectively call their assert function 'ass()'

Assert failed. Expected '2 000 000' to equal '2 000 000'.

I'd like to say that didn't take me 3 hours to figure out... I'd really like to!

Yesterday was the first day of an "Advanced" C programming class. I looked at the first homework afterwards and saw this:

NEVER use 'assert'. Real programmers don't use assert in big software projects because it makes your code stop.

Who the... What... How... Why would you...

*sigh* it's going to be a long two months.

how to php, an infographic by Bind (that me)

0) assert your goal, in this example let it be sending an email from the server
1) search for implemented methods
2) all you can find is either outdated or not helping at all
3) think of solution in any other language (eg c# or node)
4) implement 3)
5) iterate until you have something that works but you have no idea why
6) after 1 week, realize that there is a built in method, but its called userData_registration_sEnder0(adress, header, egg, pinNumbe_r, message)
7) cry

So after 7 months of soul crushing searching I was able to land an awesome job I never thought I'd get! I didn't really get hired for my projects, I think I was more of a culture fit that knew enough of what they were talking about. My colleagues are awesome, helpful people but they are also clearly way ahead of me as devs. I know that many new hires have similar feelings and it's more a matter of drive + time. I understand that and I'm ready for the marathon ahead of me but I have one HUGE concern... I don't understand unit testing. I've never written unit tests in JavaScript or Java (just on paper I wrote random assert statements for a college exam question that somehow turned out correct). More importantly, I don't understand when to write unit tests and what my main objectives should be when writing them. At work they talk about unit testing like it's just as basic as understanding version control or design patterns, both of which I have had no problems asking questions about because I at least understood them generally. I come here looking for resources, mainly things I can go through over the weekend. I understand that I'm going to have to ask my colleagues for help at some point but I DON'T want to ask for help without any solid base knowledge on unit testing. I would feel much more comfortable if I could understand the concepts of unit testing generally, and then ask my team members for help on how to best apply that knowledge. I'm sorry for begging, I'll definitely be looking for resources on my own too. But if anyone could point me to resources they found to be helpful & comprehensive, or resources that they'd want their co-workers to use if they were in my position I would be very grateful!!!!

Everytime I am developing an API (from scratch, not when extending an old one) I try to return 418 HTTP error code in places that aren't yet developed or mainly when something that shouldn't have happened did actually happened. (example: failed non-essential assert, yes python)

So it's always lighter on lungs seeing people running around with wtf.png faces when their browser says "I AM A TEAPOT".

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.

Unicode's biggest problem is that it isn't a streamable format. Given a section of a Unicode string, it's impossible to assert that the next character won't be an accent or zwj or other modifier. This means that it's impossible to convert stdin into an iterator over canonicalized Unicode graphemes.

Lessions I learned so far from my first big node/npm project with tons of users:
1) If you didn't build something for a while, expect 3 hours of resolving version conflicts for every two weeks since the last build.
2) Even if the tests pass, run the containers on your own machine and make sure that the app doesn't randomly crash before deploying
3) Even if the app seemed to work on your own machine, run the tests again in an environment mimicking prod at most 15 minutes before replacing the running containers.
4) Even if all else indicates that the app will work, only ever deploy if you expect to be available within the 4 hours following a deployment.
5) Don't use shrinkwrap for anything other than locking every version down completely. A partial shrinkwrap will produce bugs that are dependent on the exact hour you built the app _and_ the shrinkwrap file, and therefore no one will ever have seen them other than you.
6) Avoid gyp, and generally try not to interface too much with anything that doesn't run on node. If parts of your solution use very different toolchains, your problems will be approximately proportional to the amount of code. And you'd be surprised just how much code you're running. (otherwise it's more logarithmic because the more code the less likely a new assumption is unique)
7) Do not update webpack or its plugins or anything they might call unless you absolutely need to
8) Containers are cool but the alpine ones are pretty much useless if you have even just one gyp module.
9) There's always another cache. To save yourself a lot of pain, include the build time in every file or its name that the browser can download, and compare these to a fresh build while debugging to assert that the bug is still present in the code you're reading
+1) Although it may look like it, SQLite is far from a simple solution because the code and the bindings aren't maintained. In fact, it'll probably be more time consuming than using a proper database.

I'm a strong believer in the triple-A unit-test pattern: Arrange, Act and Assert

Anyone else that uses this for their tests? Do you see any cons to using this approach to writing tests? Are you using an alternative?

I think I need glasses (or at least more coffee) but every time I think about contributing to an open source project maintained by a "Comunity", i find out that I missed the smelly bits in theire massive coc that they want to ram down your throat.

Eigther I missed them every time or some fuck puts them in after I read them.

The first time it's about mostly Standart shit like: don't troll/flame/insult/detract. But than I start seeing: Sexism, Racism, xenophobia, hetotonormativity (wtf nodeJs)/homophobia insta ban. They even assert that you should apologize even if you did nothing wrong and your not allowed to stand your ground or your banned.

And if the mod pulls a fast one on your buddy, not allowed to be discussed in any public forum or your banned too.

What happened? I was sure that only the bigger repos had that shit (like the Linux kernel (that bans you for being pro trump). Have I missed something?

Fuck every repo that does that shit. They ain't gonna get my time or money.

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

# Test MyService

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

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

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

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

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

In the same test file, 3 different tests, same field…

assert thing.is_blue
self.assertTrue(thing.is_blue)
assert thing.is_blue == True

…and of course other tests…

assert not thing.is_blue
self.assertFalse(thing.is_blue)
assert thing.is_blue == False

Unit test is close enough.

assert(true, "Okay if this fired then we are _screwed_.");

Someone, somewhere, in the standard C library headers for my particular libc implementation, is #undef'ing assert() unconditionally and it's causing massive headaches.

Fuck the C preprocessor. There's no way I can track this down it seems, but my assert implementation is being quietly ignored and I have no recourse for it.

Gotta change all of my asserts to a different name now. Fun.

*long sigh*

/**
* Refund Test Assert
* If this block makes it into production
* I made it as a developer
**/
for(var sub : subscriptions)
if(sub.hasEnded()) refundCustomer(sub.Id);

What a mess ^^

From one moment to another unit-tests on my local machine stopped working.

There was a PHP fatal error, because of insufficient memory.

Actually, there was a ducking "unit"-test of a controller action "log".

This action returns the content of the projects log file...

Since this log file grew over the time, PHP tried to assert the response of the controller action which was sized about 400MB.

C'moooooon guys!
What were your thoughts behind this bullshit? ^^

I hate this crap and wish people would stop doing it. It makes my brain bleed and doesn't prevent any difficult to find bugs.

if (TERMINAL_COUNT <= index_thing)

English doesn't work that way, and I don't know about you but this crap is just awkward as hell. Sweet Jesus I wish there was less cargo cult programming in the world. Just because you saw something in a blog that convinced you that reverse comparisons is best doesn't mean it actually is. Use a damn static analysis tool to catch accidental assignments in expressions, don't twist my brain to interpret your weird phrasing of comparison operators. Some of your code reviewers may be dyslexic and have enough problems as it is.

And now for the mini-rant that I'm actually here for: You know what makes for difficult to find bugs? (Hint: It sure as hell isn't an assignment in an expression) Releasing an RTEMS semaphore you've never obtained. You'd think that would cause some kind of panic or assert failure but nope. Instead it causes... misaligned address exceptions? In statically allocated global memory? WTF??

When you aint suspicious until the assert fails :q

So my boss asked me to create an integration with a governamental program. This integration consisted in a text file being sent in a monthly basis.
Months later, he asked a coworker to automate the process, since the appointed user was finding the work too..."tedious",and asked me to check on the former regularly.
Thing is, everytime I checked, I saw a change being done in the core of the business layer, and I intervened, saying that those changes were either unnecessary or wrong altogether.
After three of these interventions, said coworker asked my boss to "ask" me to stop, and let him do his work. The boss concedes.
At the end of the week, my boss asked me to review the final product, and assert whether it conformed to our patterns.

After said review, he asks me why I've denied the work, to which I answer "a) the rules were changed by (the coworker), and are no longer correct, b) the the automator still requires a user intervention, and c) it threw an exception in the first time I (and I guess we) tested".

The job was placed in my time line the following day.

I'm scared I will assert something is a certain way when actually it isn't. It's not that I hate being wrong, I'm wrong all the damn time, I just don't want to be seen as someone with a big ego who can't take the time to learn what's actually going on.

This results in my constantly saying "I think" and "maybe", which makes me sound less confident and likely results in being taken less seriously. But I think I prefer that to sending someone down the wrong path if I'm not sure I know what I'm saying is correct.

Make an Async task (Java) and...

DONT use a loop to iterate though a time series collection. Don't linear search that shit.

DO use a queue and pop() it like its hot. Check that shit to see when it needs to be used instead of searching.

DO assert that your time series data is in order (Predication mother fucker).

DO throw an exception that you data is all fucked when it's all fuck up.

Stay sexy and use a fucking queue man.

ni'o lei temci cu flecu pe'a .i la .varik. cu jdika le ka lo nu ce'u fanva fi le glibau fo la .lojban. cu zmadu lo nu ce'u glibau ciska je ba'e nai cu fanva fo la .lojban. kei le ka ce'u xi re frili ce'u
.i le su'o prenu cu xusra ko'a goi le du'u to'e frili fa lo nu jimpe fi lo selci'a be la .varik. be'o poi xe fanva fo la .lojban. .i ku'i la .varik. cu toltu'i fi ko'a

Time "flows". The extent of that (the extent of that (VARIK finds that translating from Lojban and to English is easy) is greater than the extent of that (VARIK finds that writing English stuff and not translating is easy)) increases.
Some prenu assert that difficult is that reads VARIK's writing which is translated from Lojban and to English. But VARIK disagrees.

#define SOAPBOX

Data will contain errors and inconsistencies, and the only player that can detect them is: the computer itself.

if the computer detects that it is in a situation where it cannot meaningfully continue, it should not allow itself to continue.

Only the computer can make that determination.

If the software does not aggressively test its data, it is usually impossible to determine whether the problem is with the software or with the data or both.

Per contra, if it does do so, it becomes impossible to assert that the input data does not contain the issues that are being tested for ... a very important thing to be able to say in a real-world production setting, where hundred-megabyte input files are common.

#undef SOAPBOX

[TestClass]
public class DayTest
{

[TestMethod]
public void Init_WowEnthusiasmPlusMeeting_fml()
{

// Arrange
Day monday = new Day(

Math.Ceiling(Chrizzle.Mojo),
(List<Task>)Board.GetStories()

);

int startingTaskCount = monday.Tasks.Count();
monday.AddMeeting(new Meeting(duration: 7.5));

// Act
monday.Init();

// Assert fml
Assert.IsTrue(

monday.Tasks.Count() ==
startingTaskCount &&
Chrizzle.Mojo == 0

);

}

}

// Unreachable code detected

I wish everyone would move away from code coverage as a metric and towards some kind of mutation framework.

There seem to be increasing numbers of devs getting themselves off on their "shiny 95% coverage" and patting themselves on the back for covering everything but the 5% of the codebase that actually needs thorough testing.

Oh, and that's ignoring the tests that just assert an exception isn't thrown, or don't assert anything at all. Completely bloody useless, but hey, you just carry on boasting how great all your tests are because you've got a higher coverage than the team next door 😤🙄

I don't really have a recruiter story but this will have to cut it:
I had a meeting at a web development company for a project they were outsourcing to my company (it wasn't really their area of expertise). As we walked into the building, the person we were meeting with kept saying things like, "O, those guys probably just came back from playing foosball downstairs." or "Would anybody like a cappuccino. We have like 10 machines."
To assert my resistance to this shameless charm, I declined the coffee. First and last time I say no to coffee.

The code passes the tests which i wrote for the code to pass so it must be fine. (These are only assert statements mind you)

Assert ref != NULL rather than conditional check it more often.

Silently returning / ignoring is way worse if object was meant to be valid.

The caller should deal with it. (As abstract as possible preferably...)

Obviously there's places where conditional is necessary.. but silent null checks can cause more pain than good.