Unit testing in code

DublinWriter

A particular client is looking for 'Unit testing in code' for software going through their test team.

The systems in question are C# ASP.Net webforms apps and are essentially CRUD in nature and not algorithmic.

I'm not sure it's advisable or even possible for these types of apps.

How would you approach it?

km991148

DublinWriter wrote: »

A particular client is looking for 'Unit testing in code' for software going through their test team.

The systems in question are C# ASP.Net webforms apps and are essentially CRUD in nature and not algorithmic.

I'm not sure it's advisable or even possible for these types of apps.

How would you approach it?

For adding new pages or existing?

It is possible - previously we would use MVP patterns on webforms, these days there are simpler ways to inject dependencies into the code behind of pages which gives you some options to build upon (inject in abstractions and test those).

I would probably start off by testing page dependencies and then if you need to test the pages themselves, look towards MVP patterns.

Depends what the client is looking for? Some level of confidence or general "We need unit tests" for the sake of it.

Mr. CooL ICE

It sounds like the webforms app you are working on has all the logic in the server codebehind section, so unit testing probably isn't possible if your .cs file is thousands of lines long.

One possibility would be to create a static method library and refactor as much of the existing codebehind code into it. That way, it would be possible to unit test certain sections of it.

FWIW, I've never worked on unit tests in a webforms app and any webforms I've worked on have been unmaintainable messes, but if I were in your situation and the client insists on it, that would be the way I'd go.

igCorcaigh

DublinWriter wrote: »

The systems in question are C# ASP.Net webforms apps and are essentially CRUD in nature and not algorithmic.

Even so, validation could be abstracted out and made unit testable.

km991148

Mr. CooL ICE wrote: »

One possibility would be to create a static method library and refactor as much of the existing codebehind code into it. That way, it would be possible to unit test certain sections of it.

Why static tho?

DublinWriter

Mr. CooL ICE wrote: »

It sounds like the webforms app you are working on has all the logic in the server codebehind section, so unit testing probably isn't possible if your .cs file is thousands of lines long.

Each form has its own codebehind .cs file plus there's a library of generic utility functions. There's a DAL, but no BAL.

km991148

DublinWriter wrote: »

Each form has its own codebehind .cs file plus there's a library of generic utility functions. There's a DAL, but no BAL.

So its more that its too simplistic (you said CRUD type) with no real business layer?

I would ask what problems are they trying to solve with UNIT testing. Is it confidence building, are there existing issues (i.e. refactoring that went wrong) as it sounds like the disruption and investment required may not be worth it and other forms of testing (UI automation/ integration testing or something else) may be more beneficial.

If its new work being added, then I would seek to ensure that is unit tested as it's not disruptive to introduce a new pattern.

igCorcaigh

DublinWriter wrote: »

Each form has its own codebehind .cs file plus there's a library of generic utility functions. There's a DAL, but no BAL.

I'd be best putting my efforts into integration testing in this scenario.

Still, there may be utility functions for working with dates and such, and validation as I said. All that stuff can be put into classes and unit tested.

I don't understand why the client is asking for unit testing in particular, personally I would push back on this.

DublinWriter

igCorcaigh wrote: »

I don't understand why the client is asking for unit testing in particular, personally I would push back on this.

I think I understand why - a few people probably were sent on a DevOps course recently and came back loaded-up with the latest industry buzzwords without a decent understanding of their meaning and context.

I intend to push back on this.

The only rationale I got from management was that they are now following "Modern Software Engineering" practices. Bear in mind that they are still following a Waterfall model for delivering IT projects from the smallest 10-user system to major enterprise rollouts and have resisted Agile at every turn.

km991148

DublinWriter wrote: »

I think I understand why - a few people probably were sent on a DevOps course recently and came back loaded-up with the latest industry buzzwords without a decent understanding of their meaning and context.

I intend to push back on this.

The only rationale I got from management was that they are now following "Modern Software Engineering" practices. Bear in mind that they are still following a Waterfall model for delivering IT projects from the smallest 10-user system to major enterprise rollouts and have resisted Agile at every turn.

I am not clear tho - is this for new development on an existing app or is it to add unit tests to the existing CRUD webforms app.

It still doesn't seem like there would be much value and its on the basis of value (however you quantify it) that you should push back (otherwise it just sounds like "I don't like it").

DublinWriter

km991148 wrote: »

I am not clear tho - is this for new development on an existing app or is it to add unit tests to the existing CRUD webforms app.

It's for a six-year old CRUD webforms app that's being updated and has gone through their internal testing twice previously.

km991148

DublinWriter wrote: »

It's for a six-year old CRUD webforms app that's being updated and has gone through their internal testing twice previously.

ye, probably not worth the levels of refactoring needed to introduce unit testing. Some examples of how much effort is required with the risks presented back to management as well as some alternative strategies (to unit testing) should work.

Unless the y have other plans to develop more features that you don't know about?

GreeBo

Give them a price for wrapping those apps in Selenium/BDD and see what they say?

BrokenArrows

If they want to introduce unit testing to an existing product then they need to introduce it in stages.

1. All new features must include unit testing. This will stop the problem getting worse as time progresses.
2. Introduce what unit tests are possible without having to refactor existing code. Likely to be fairly simple stuff but its better than nothing.
3. Gradually refactor code to make it unit testable.

DublinWriter

All ended well - client's test team agreed it was a nonsense

Turns out it was a requirement arbitrarily added on by clueless middle-tier consultant who recently attended a Microsoft workshop.

John_Mc

DublinWriter wrote: »

All ended well - client's test team agreed it was a nonsense

Turns out it was a requirement arbitrarily added on by clueless middle-tier consultant who recently attended a Microsoft workshop.

To be fair, I don't think wanting software to have a suite to unit tests to prevent regression is a bad idea. It is the way things should have been done in the first place.

counterpointaud

Yeah it can be hard to add unit tests after the fact for older frameworks like that, that don't lend themselves to things like dependency injection and mocking. May use something like Cypress for e2e / integration tests instead? You get more coverage with less code that way anyway.

igCorcaigh

counterpointaud wrote: »

May use something like Cypress for e2e / integration tests instead?

Interesting. First I have heard of Cypress.

Would this work will in a tightly written CRUD type application like that described by the OP?

counterpointaud

igCorcaigh wrote: »

Interesting. First I have heard of Cypress.

Would this work will in a tightly written CRUD type application like that described by the OP?

If it has a UI that runs in a browser, then yes, why not?