patrick.net

Must only be use to aisan shifter.

www.youtube.com/embed/2ecBCfu7yW4

Look at the idiot leaning away from his baby leaving her exposed for the brunt of it, if it goes his way.

I hope the dude that took it on the chin gets to keep it. Not that it will ever be worth much with the decline of American Sportslore.

@Hassan_Rouhani saw you posted a link to this which would not auto-load. Reposting for you after downloading it and compressing:

Patrick says

@Hassan_Rouhani saw you posted a link to this which would not auto-load. Reposting for you after downloading it and compressing

Tnx, Pat!

New slow cooker

Help me better nurture my inner Nerd Patrick I don't get it.

I don't do Unit Tests I think they are a waste of time, and end up being the targeted audience for software that is written while diminishing the real end users needs.
Unit Tests are so socially promoted people get to work in IT and feel useful.

Tenpoundbass says

Help me better nurture my inner Nerd Patrick I don't get it.

I don't do Unit Tests I think they are a waste of time, and end up being the targeted audience for software that is written while diminishing the real end users needs.
Unit Tests are so socially promoted people get to work in IT and feel useful.

I think it means that while all unit tests are passing the software is often catastrophically flawed, similar to your comment. I agree with the total exaggerations and overabundance of unit tests which are most often not very useful. Also what often happens is that al the tests pass but that crucial specific test case that happens in production is not being tested and breaks the code, then a regression unit test is written but the code never fails at that spot again since it was fixed. Once in a while regression tests catch something to be fair. The worst though is TDD where people write tests first and there is no product for the first 6 months, then the tests will get rewritten to fit the product once it's finally there. I'd rather employ one or two good QA coders who find ways to break the code, functionally and under stress, file bugs while the DEV team simultaneously fixes them.

mell says

The worst though is TDD where people write tests first and there is no product for the first 6 months, then the tests will get rewritten to fit the product once it's finally there.

You know waterfall's not a real methodology right?

While integration and UAT are certainly more important to the big picture, a failing unit test is not without benefit.

NuttBoxer says

mell says

The worst though is TDD where people write tests first and there is no product for the first 6 months, then the tests will get rewritten to fit the product once it's finally there.

You know waterfall's not a real methodology right?

While integration and UAT are certainly more important to the big picture, a failing unit test is not without benefit.

There is no waterfall anymore in SW engineering, it's all more or less agile. Unit tests are fine to a certain extent, but their importance is totally overstated. That being said, I'm talking about the rudimentary minimal unit tests written by the developer, or add-on tests for a new feature/regression. Ideally the majority of the unit (and integration) tests should be written by somebody else than the developer so there is no bias or shortcut (due to feature/time pressure), like a skilled QA coder.

mell says

There is no waterfall anymore in SW engineering, it's all more or less agile. Unit tests are fine to a certain extent, but their importance is totally overstated.

If you have a properly normalized data model with attributes and types stored in their own table. 99% of every SW break on my projects, are fixed by someone creating a record for the new product launched. This is why I prefer to work alone. I get flack all the time from other technical observers asking why I build so much back end when they would just hard code a bunch of crap and whip the app together. I factor and build in so much contingency, and admin tools, I rarely find a broken record that can't passed through data entry through the software I wrote. When people drop the ball in other areas and try to blame my app, I even save the XML to show them that's how the record came down.
For all of the trouble unit Testing makes for useless results and your dead in the water and need more code. I prefer a more pragmatic Cover Your Ass(code) approach.
I often laugh at how easily new requirements integrate into what I've already wrote. If you're business logic and business models are suited for the vertical you wrote for.
There shouldn't be much development work required. I'm working on a EDI X12 850 Sales Order parser, because just parse line by line and throw it directly in the SalesOrder tables we already have. Once it was parsed and inserted, the rest of the requirements were already baked in.

Unit tests my ass it either works or it doesn't. If I'm going to write frivolous copious amounts of code. I would rather build the Super Admin Dashboard of God.