programmatically get to the little number in the VCR controls at the bottom of a form

[Phlip]

Access is an excellent development tool to use in many scenarios. But this
isn't one of them.

I bet you MVPs could do it.

(But I ain't hanging my project on that..

 

[Brendan Reynolds]

I did not say that it was impossible. But I do not believe that it is
practical.

 

[Phlip]

I did not say that it was impossible. But I do not believe that it is
practical.

When I write an article on my experiences I'l remember to solicit reviews
here.

But, for the present, I stuck on the latest version of VbLiteUnit.dll, or
something, is making Access crash when I hit <Alt+F11>. So you might be
right, for the wrong reasons...

 

[Tony Toews]

Okay. Call each little manual test an "experiment". Now imagine if you
encapsulated each experiment into a test case in a test rig.

If you run that over and over again, you can run it after each _tiny_ change
to source. The test rig will perform all those experiments, over and over
again.

That, of course, is obvious. But, in general, is pointless. You
have some code behind a form doing some data validation. It works or
not. If you ever go back and make some changes then test it again.

You are saying that it's only a little debugging so why worry about it.

Basically yes.

The next benefit of TDD is you can change things much more aggressively. You
could, for example, refactor all your data tables, normalize them, rebalance
them, etc. If the tests still pass, the application is deliverable.

"Refactor your data tables, normalize and rebalance them." I have no
idea what those terms mean in the context of databases. Besides
normalizing of course.

But my systems are normalized properly from the beginning. So that's
not a concern to me.

Now if I had to do a conversion of the backend MDB to SQL Server I can
understand where this would be of more interest. But again ninety
percent of the forms just require you to enter some data and ensure
you get the expected errors and the data makes it to the tables.

This is why I must ask sick questions here. If I word them poorly,

If anyone words questions poorly we ask for clarification. And quite
often what their objective is as we can likely suggest some
alternatives.

MVPs
might respond with the manual intervention to avoid what I was trying to
automate. TDD for databases is hard, and for GUIs is exceptionally hard.

Access is both. That's why I'm exceptional. ;-)

Ok.

I simply don't see the need for spending a lot of time
programmatically stuffing a form with data and then seeing if the
table has that data.

For very complex algorithms I can see that. But I'd say 90% of what I
do isn't that complex. In fact it's rather boring. And I suspect I
work on larger, more complex apps than most people including many
MVPs.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm

 

[Phlip]

That, of course, is obvious. But, in general, is pointless. You
have some code behind a form doing some data validation. It works or
not. If you ever go back and make some changes then test it again.

The VBA culture is steeped in a technique that the book /Domain Driven
Development/, by Eric Evans, calls "Smart UI AntiPattern".

(No, I am not representing I have read all 576 pages of that book!)

To write a GUI very rapidly, you neglect design considerations, and get it
working in its default configurations. Access is essentially a kit for
building GUIs linked to databases, facilitating this AntiPattern. It comes
with a ready-made design, so our code design is less important.

I seek to make this AntiPattern sustainable.

"Refactor your data tables, normalize and rebalance them." I have no
idea what those terms mean in the context of databases. Besides
normalizing of course.

refactor - change structure while leaving behavior the same
normalize - I hear DBAs say that so I put it in the list
rebalance - tuning so transactions are brief & schemas are pretty

But my systems are normalized properly from the beginning. So that's
not a concern to me.

And when your customers change requirements, per Eric's book, you just write
a new application.

If anyone words questions poorly we ask for clarification. And quite
often what their objective is as we can likely suggest some
alternatives.

The last time it took several tries before someone "got" it.

If I say too little, I get a canned response targeting newbies and
mouse-abuse, and if I say too much we accidentally spark a TDD debate
thread.

Wash your hands before performing surgery, folks...

I simply don't see the need for spending a lot of time
programmatically stuffing a form with data and then seeing if the
table has that data.

Debugger-driven development gets slower and slower as a project scales. I
seek the opposite effect, where new features get easier and easier to add.
(Technically, the test cases become easier and easier to write because
test-side methods to stuff a form and such are available and polished.)

This means programming systems with wizards, designed to start a project
very fast, for me start very slow!

 

[Tony Toews]

To write a GUI very rapidly, you neglect design considerations, and get it
working in its default configurations. Access is essentially a kit for
building GUIs linked to databases, facilitating this AntiPattern. It comes
with a ready-made design, so our code design is less important.

I seek to make this AntiPattern sustainable.

Ok, I don't really know what you are saying here.

refactor - change structure while leaving behavior the same
normalize - I hear DBAs say that so I put it in the list
rebalance - tuning so transactions are brief & schemas are pretty


And when your customers change requirements, per Eric's book, you just write
a new application.

No idea where you got that from. If they change requirements you
update the system to match the new requirements. Happens all the
time. Business change, they get new clients with new data
requirements and/or they want to fine tune things.

The last time it took several tries before someone "got" it.

If I say too little, I get a canned response targeting newbies and
mouse-abuse, and if I say too much we accidentally spark a TDD debate
thread.

Wash your hands before performing surgery, folks...
Ok.


Debugger-driven development gets slower and slower as a project scales. I
seek the opposite effect, where new features get easier and easier to add.
(Technically, the test cases become easier and easier to write because
test-side methods to stuff a form and such are available and polished.)

Ok, if you say so.

This means programming systems with wizards, designed to start a project
very fast, for me start very slow!

Well, have at it.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm

 

[Phlip]

Ok, I don't really know what you are saying here.

No idea where you got that from. If they change requirements you
update the system to match the new requirements. Happens all the
time. Business change, they get new clients with new data
requirements and/or they want to fine tune things.

I am saying I am researching how to do any kind of big change with zero
bugs.

Not "I know where the bugs will be so I'l run the debugger over those parts,
and they will just be easy little bugs."

Zero bugs.

 

[Brendan Reynolds]

As you wish. It's your time.

 

[Phlip]

Well, have at it.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvs05/html/vstsunittesting.asp

"There are several unit testing best practices to review before we close.
Firstly, TDD is an invaluable practice. Of all the development methodologies
available, TDD is probably the one that will most radically improve
development for many years to come and the investment is minimal. Any QA
engineer will tell you that developers can't write successful software
without corresponding tests. With TDD, the practice is to write those tests
before even writing the implementation and ideally, writing the tests so
that they can run as part of an unattended build script. It takes discipline
to begin this habit, but once it is established, coding without the TDD
approach feels like driving without a seatbelt."