is an all-in-one system for building databases, but:
- It can't do everything
- It uses objects, but doesn't have all the object "stuff" (Inheritance and what have you)
How can you apply ExtremeProgramming
practices (or even object based development) to Access?
There is VbaUnit, which was developed for a MicrosoftAccess project.
VBA is very close to VB, so you can do lots of stuff in MicrosoftAccess, just as you can in VB. You can create classes, but you'll have to get familiar with VB's retarded not-quite-ObjectOriented style, especially its DelegationInheritance scheme (see also InheritanceInVbClassic). Regardless, it is possible to do XP in Access, just not as easy as say Java or Smalltalk.
I tried, and that was the only project I ever abandoned for TestDrivenDevelopment
Access has thousands of "conveniences" that help wizard-driven development.
They interfere, mercilessly, with all phases of test case creation - with the AssembleActivateAssert
cycles in test cases. There was no way to tell the helpful nag windows "yes I KNOW that record is partially formed - I'm just going to test something with it then throw it away!"
Switch to RubyOnRails
with an Access driver for the back end.
There is a UnitTesting
tool for Access called AccUnit?
). I use it intensive and it works out pretty nice. Version 1.0 to be released soon.
If there are more than two developers working on an MS-Access program, then MS-Access is probably the wrong tool. You'll drive yourself crazy trying to give it an "Enterprise Flavor". MS-Access is like the Millennium Falcon: it's out-dated, cheap, it mostly works, you have to bang it a lot with a wrench to keep it going, and if you sneeze wrong you'll have to restart it with the wrench again.
But it's the fastest database in the galaxy?