IT/Software career thread: Invert binary trees for dollars.

Deathwing said:

The pen testing people that we hired to test our hub were next to useless. Definitely closer to mindless automatons just following a script. For a software test engineer, I want people that wrote that script and the accompanying software.

Click to expand...

Pentesting =/= paying someone to run a nessus scan. So many "security" companies sell pentests with just that in mind and it is a disgrace to the industry.

So it looks like we're going with a WISA stack and not a LAMP stack for our project cause one of our consultants is familiar with C# and ASP. I guess it's not a huge deal either way, I'm just worried we'll be stuck in a position where it's a pain in the ass to update the framework and it'll be a huge ordeal to get necessary changes pushed through.

James said:

So it looks like we're going with a WISA stack and not a LAMP stack for our project cause one of our consultants is familiar with C# and ASP. I guess it's not a huge deal either way, I'm just worried we'll be stuck in a position where it's a pain in the ass to update the framework and it'll be a huge ordeal to get necessary changes pushed through.

Click to expand...

Some people have a hard time updating applications to newer versions of the framework and I honestly never understood why (unless of course they don't have the source anymore). You basically open it in Visual Studio, target the new framework, then right click all of the squiggly lines and let it refactor for you. Whatever doesn't work out, you can usually figure out how to rewrite on your own in a few minutes. I've done this for many applications that "couldn't be updated!" over the years and never encountered much of an issue.

I was more thinking about like updating SqlServer or going to a new Windows server version. I really want to get a MEAN stack in here, but don't know anyone with the expertise to walk me through all the little details of it, let alone how to start developing in it.

Angular is dead imo. MERN!

James said:

I was more thinking about like updating SqlServer or going to a new Windows server version. I really want to get a MEAN stack in here, but don't know anyone with the expertise to walk me through all the little details of it, let alone how to start developing in it.

Click to expand...

Updating windows and SQL Server is point and click easy shit. You can still run .net 1.1 apps on modern Windows/SQL. I'd have zero worries about long term support on a .NET app.

Nah, ASP.

I want to get y'alls opinion on an argument that's raging at work in regards to unit vs integration testing and what's valuable to test and what isn't.

I'm not sure I can explain this clearly without going into a lot of detail about how or application is constructed. But suffice to say, what is happening, I feel, is that our integration tests are testing way too much of the WebAPI framework itself (which is out of our control) and not our application. They are doing these monolithic end-to-end tests that go from the HTTP service and API controller all the way to the database. Our application follows a pattern of API controller -> DataServiceProvider -> Datastore. Generally speaking, our API controllers do nothing more than call a service provider's method -- i.e. "get me data for this id, save this model, etc'. No business logic at all exists in the API controllers.

These integration tests have to go through all this rigmarole setup and teardown that, in my opinion, is a complete waste of time and resources. My argument is that the only real value is testing the service providers as far as integration tests go. As developers we can write unit tests to confirm that a controller is making a call to a provider, but what that provider does I don't give a shit about from the controller's point of view. Also I don't care about HTTP calls to the API controllers because, again, we aren't handling those anyway. The webAPI framework sorts all that stuff out, so why bother testing it? Again, we can write unit tests to confirm that a controller has the correct route and other details -- I don't need to physically make a HTTP call to the controller to make sure "it works".

My assertion is, don't write tests that are mostly just testing the framework (in our case, ASP.NET WebAPI). Another quick example: they will often write tests to confirm data is saved to the database. So, what are you testing? That SQL server works? I've literally seen tests that do only that and aren't actually testing any business logic. In my opinion this is dumb but maybe I'm off base here.

Fuck tests of code you/your team didn't write i.e. framework/library tests. WTF that's not your problem. Get coverage on shit you did.

That's why it's called integration testing. You are testing how your system integrates with another. It sounds like you want unit and integration testing to be the same thing. But they aren't.

wilkxus said:

TLDR; Yes... you need Integration testing, and other testing well beyond *just* Unit tests. Unit testing is only a very small part of the overall testing puzzle in larger applications. At best Unit and Integration testing are equally important, at worst much of Unit testing is of dubious benefit. Research cows have not come home yet with a conclusive verdict and the jury is still out on most of the claimed benefits of TDD.


From my experience here are a few.....

Spoiler: things to Consider on testing.....

I would highly suggest reading up some more on your own and reconsidering this opinion before engaging your peers @ work.

Perhaps you might want to consider backing off the Unit testing Koolaid a little and drink up a little reading on various types of testing in the software lifecycle. The whole TDD and Unit testing obsession might be well intentioned (and has potential for many benefits) but in practice is often giving new generations of developers a false sense of security.



Think of the whole application not just your little individual parts. How are you going to test your *external* dependencies? And how will your pieces of code work and interact in reality with other developers code and external services? Remember Unit tests work in *isolation* only *mocking* many interactions right? How do you intend to REALLY test those *mocked* interactions?



Hmm, this is an actual real test of your application and ideally what you WANT to do in testing: ie check whether you and your team developed a solution that actually works in real life, as opposed to mock white box testing of theory of components in isolation.

Integration testing > Unit testing
(real system components actually being tested for *real* interactions) > (mocked system components tested in isolation).
> : means it is AT LEAST as important as. Both have their place​

Think of testing this way though. You want a comprehensive testing framework to ferret out as many types of bugs and issues as possible. Unit tests really only cover a small trivial subset of potential bugs. The most difficult and important bugs often come from unpredicted, unforeseen and untested interactions and effects beyond your unit level design implementation.

Click to expand...

Yeah I'm not suggesting (at all) that unit testing is good enough and not to bother with integration testing. What am I saying is don't waste your time doing loads of integration tests that test components of your system that you did not develop and have no control over.

But here is another silly example:

Say you are developing a new GPS app for a car. One of the requirements is that when the driver turns their car the screen rotates to orient the new position. Would you write tests to confirm that when the driver turns their steering wheel that the wheels of the car actually turn? My point is, NO you would not. I think it's safe to assume the car's steering wheel is actually doing what it's supposed to.

Lendarios said:

ShakyJake are you using IHttpActionResult ?

Unit Testing ASP.NET Web API 2

Unit Testing Controllers in ASP.NET Web API 2


just do that, it should be sufficient.

Click to expand...

Yeah we're doing exactly that. However, our test team is also writing tests that new up HttpClient to call the endpoints. My argument is that doing this is pointless and proves nothing (other than, yes, IIS is works).