ideal sprint fallacy.
total days 10 , total hours(excluding breaks ) 8 hrs per day= 80 hrs per dev

code freeze day = day 8, testing+ fixing days : 8,9,10. release day : day 10
so ideal dev time = 7days/56 hr
meetings= - 1hr per day => 49 hrs per dev

- 1 day for planning i.e d1 . so dev time left . 6 days 42 hrs.
-----------
all good planning. now here comes the messups

1. last release took some time. so planning could not happen on d1. all devs are waiting. . devtime = 5 days 35 hrs.

2. during planning:
mgr: hey devx what's the status on task 1?
d: i integrated mock apis. if server has made the apis, i will test them .
mgr : server says the apis are done. whats your guestimate for the task completion?
d : max 1-2 hrs?
m : cool. i assign you 4 hrs for this. now what about task 2?
d : task told to me is done and working . however sub mgr mentioned that a new screen will be added. so that will take time
m : no we probably won't be taking the screen. what's your giestimate?
d : a few more testing on existing features. maybe 1-2 hrs ?
m: cool
another 4 hrs for u. what about task 3?
d : <same story>
m : cool. another 4 hrs for u. so a total of 12 hrs out of 35 hrs? you must be relaxed this sprint.
d : yeah i guess.
m cool.
-------
timelines.
d1: wasted i previous sprint
d2 : sprint planning
d3 : 3+ hrs of meetings, apis for task 1 weren't available sub manager randomly decided that yes we can add another screen but didn't discussed. updates on all 3 tasks : no change in status
d4 : same story. dev apis starts failing so testing comes to halt.
d5 : apis for task1 available . task 3 got additional improvement points from mgr out of random. some prod issue happens which takes 4+ hrs. update on tasks : some more work done on task 3, task 1 and 2 remains same.
d6 : task1 apis are different from mocks. additionally 2 apis start breaking and its come to know thatgrs did not explain the task properly. finally after another 3+ hrs of discussion , we come to some conclusions and resolutions
d7 : prod issue again comes. 4+ hrs goes into it . task 2 and 3 are discussed for new screen additiona that can easily take 2+ days to be created . we agree tot ake 1 and drop 2nd task's changes i finish task 2 new screens in 6 hrs , hoping that finally everything will be fine.

d8 : prod issue again comes, and changes are requested in task 2 and 3

day 9 build finally goes to tester
day 10 first few bugs come with approval for some tasks
day 11(day 1 of new sprint) final build with fixes is shared. new bugs (unrelated to tasks. basically new features disguised as bugs) are raised . we reject and release the build.

day 2 sprint planning
mgr : hey dev x, u had only 12 hrs of work in your plate. why did the build got delayed?

🥲🫡

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

Not dev, but a perf-eng confidence boost.

Our company was hired by a client to onboard perf-testing process and do some perf-related go-live stuff. Basically, make sure the app meets the SLAs.

Our company mobilized some internal resources for the task. The had 3-4 months. 2 months later they realized they won't pull it off. What a shame...

When the threat of dropping the ball and losing the client and recommendations became very real, they engaged us. Half the time, half the resources, a worried and annoyed client who now wants to control the whole initiative.

During the first 2 meetings we get the general idea of what they have, what they want. We take some time to prepare a plan to make it on time. The client argues our plan, mostly because one of the main points was mocking downstream dependencies [integrations]. He asks, then demands to do it all with live integrations. We explain why this is an incredible risk and why we should do it the proposed way. He disagrees.

Alright then... Maybe he knows smth we don't. Let's do it the risky way...

A month later test results are far from the target. I did my best with app de-bottlenecking and fine-tuning. But since the live integrations do not deliver, they hide other bottlenecks. The initiative is stuck.

Finally, the client agrees to do it with mocking. But now there's no time left as it will take almost a month to prepare mocks...

The client agrees we should have done it our way from the start. They postpone the go-live and we carry out our testing and tuning the right way.

That was one expensive and long "I told you so". But it boosted our [perf team's] confidence to the top and beyond :)

don't tell us how to do our job, unless you do want extra expenses

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?

React Native testing is hair pulling.

Every test needs to have 100 different mocks in place and there are: 3 different methods to mock a function (mock, mockImplementation, and fn), 3 different types of query methods to get elements (get, find, and query), and 5 different selectors to query on (accessibility label, testId, accessibility hint, accessibility value, etc.)

And after reading all this, being diligent and learning the difference between stupid, synonymously-named functions which have wildly different side effects like "getByA11yHint" and "findByA11yHint" (ugh...), after all that, you write out a test with all the appropriate mocks and you want to do something simple and it beats you up all over again.

Button enabled or button disabled. Simple right? Logically the former is "expect(elem).toBeEnabled()" and the latter is "expect(elem).not.toBeEnabled()", right?

Wrong! You're an imbecile. Your tests will fail and never tell you that ".not.toBeEnabled()" and ".toBeDisabled()" don't do the same thing even though they look and sound exactly the same. Only the latter will work. The former makes all your tests fail. Where is this written in the docs? Nowhere?! Great!

👌😄🔫

I frigging hate unit testing an AngularJS application. The amount of mocks you need to create just to test a a piece of code is unbelievable

This is my frontend tip of the day.
If you have a frontend that consumes an external API:
1) Retrieve the json responses from devtools
2) Save them in your project as json files (trim the data a bit if it's too long)
3) When starting your app with a special env var like MOCK_DATA, make your app mock the data and use your saved json data instead.

You can associate each response with an url regex.

The package fetch-mock mocks fetch really well, it lets through the urls that don't match anything.
This way you can incrementally add responses.

And voila, you have a mode where you have near instant page loads to test things manually, and you also have mocked data ready for testing eg, cypress.

I'm an iOS developer and I cringe when I read job specs that require TDD or excessive unit testing. By excessive I mean demanding that unit tests need to written almost everywhere and using line coverage as a measure of success. I have many years of experience developing iOS apps in agencies and startups where I needed to be extremely time efficient while also keeping the code maintainable. And what I've learned is the importance of DRY, YAGNI and KISS over excessive unit testing. Sadly our industry has become obsessed with unit tests. I'm of the opinion that unit tests have their place, but integration and e2e tests have more value and should be prioritised, reserving unit tests for algorithmic code. Pushing for unit tests everywhere in my view is a ginormous waste of time that can't ever be repaid in quality, bug free code. Why? Because leads to making code testable through dependency injection and 'humble object' indirection layers, which increases the LoC and fragments code that would be easier to read over different classes. Add mocks, and together with the tests your LoC and complexity have tripled. 200% code size takes 200% the time to maintain. This time needs to be repaid - all this unit testing needs to save us 200% time in debugging or manual testing, which it doesn't unless you are an absolute rookie who writes the most terrible and buggy code imaginable, but if you're this terrible writing your production code, why should your tests be any better? It seems that especially big corporate shops love unit tests. Maybe they have enough money and resources to pay for all these hours wasted on unit tests. Maybe the developers can point their 10,000 unit tests when something goes wrong and say 'at least we tried'? Or maybe most developers don't know how to think and reason about their code before they type, and unit tests force them to do that?

when it takes more effort to writing a bunch of dumbass mocks and stubs so you can have an automated test, than it does to manually test, because you're too retarded to figure out how the fuck easymock is supposed to work, and being awful at your job, also fuck java imports and easymock for being difficult to work with

shout out to my coworkers for requesting more automated tests

can't wait till it all gets deleted anyway because we're going to delete the code we're testing

I have to mock an API for my tests. The mocks got so complicated, I basically have cloned the API at this point. Now I'm testing my mocks to make sure they work. I'm essentially writing tests for my tests. There's gotta be a better way to do this.