Testing of large ASP.NET application

[Ken]

I'd like to know how others approach testing. I work for a bank and
there are some fairly paranoid people here. My philosophy is to test
only the webforms that were changed. But people here are telling me the
whole app needs to be tested. I think that's crazy. What's your
opinion?

Thanks
Ken

 

[Guest]

I'd like to know how others approach testing. I work for a bank and
there are some fairly paranoid people here. My philosophy is to test
only the webforms that were changed. But people here are telling me the
whole app needs to be tested. I think that's crazy. What's your
opinion?

They're right - to an extent. You should have some sort of software
development methodology, which should include testing. Depending on the
scope, complexity, and importance of your application, a complete test
cycle maybe required.

However, a first good step should be to unit test your code - check out
Nunit.

If you run your base classes through Nunit at least you can be somewhat
certain that your business logic isn't broken - so although your interface
maybe buggy, at least your core logic isn't : )

To test your front end, there are several ways of doing it... but I suggest
manual testing by hand and by the users.

 

[Anders]

I'd like to know how others approach testing. I work for a bank and

there are some fairly paranoid people here. My philosophy is to test
only the webforms that were changed. But people here are telling me the
whole app needs to be tested. I think that's crazy. What's your
opinion?

It depends on how your software is structured I would say.

If you are changing business functions in a independend layer as
CreatePayment(x,x,x) then a test of the whole system could be justified. If
your only are changing presentation / or the use of such a business layer I
would say it would be overreacting.

But then again. Your statements somehow does not make sence.

If it is a bank and quality attributes such as security and safty is primary
concerns then:

1. There should be procedures to follow regarding your issue that would
overull any single developer concern.
2. If the system is a "critical" system there should be some automated test
and job of testing the would be "easy".

Are you developing a utility application to support som internal business?
If so, are you interfacing with som common business layers?

Anyway. It´s very hard to tell if you should test. If you KNOW there is no
side effects in the cahnge you made then there should be no problem (in a
non critical system). Again is it critical you would still want to test the
functionlaity. Eg. If you are recompiling youe application and a lot of
individual DLL are genereated and a corruption maybe of a bad disksector you
would still be in trouble.

Regards
Anders Kjellerup Jacobsen
Developer @ Cryos.dk

 

[Daniel]

I agree with the others, you cannot just test that your class or whatever
code you have done works and presume that all is ok (unless it is purely
cosmetic)

I also agree that re-testing the whole of a huge app just for one small add
on is a little overkill. However you should be aware as you are coding, or
before what classes, dlls and so on you are interacting with and/or
ammending. For example you may find a bug in one of the classes you are
using written by someone else and say go and 'fix' it. Great it works, now
you test your app and hey yours works. However if you don't now test
everythin else that uses that function you 'fixed' then you don't know if
your fix just broke something else.

So to keep your testing as minor as possible be sure to know what you are
touchig and what the thing your touching effects. Testing within those
boundaries should be sufficient. Personally i always do an quick overall
test of everything but i am a testing paranoid freak sometimes. However
being that way is far better than being lazy and finding a bug appearing
days/weeks later and not remembering that you changed THAT function leaving
you with the laborious debugging task.