On 07/21/20 9:13 AM, Eric Selje wrote:

Forgive me father, for I have started coding without having a plan or even a unit test written first. It's been 51 years since my last confession.

You are forgiven.  Go, and sin no more. (And we need that program yesterday)

Ah my child, I have to confess I have never in my complete development career had a plan or unit test done...

On 2020/07/21 15:13, Eric Selje wrote:

Forgive me father, for I have started coding without having a plan or even a unit test written first. It's been 51 years since my last confession.

On Sat, Jul 18, 2020 at 1:57 PM Dennis Schuette dennis@cbsds.com wrote:

...

That's such an easy change, I won't even bill you for it.

1 hour of programming, 5 hours of debugging, and 3 customer requested enhancements later, I'm almost done!

Customized Business Services, LLC (928) 580-6352 Dennis Schuette Primary: dennis@cbsds.com 49 NW 130 Avenue Alternate: Schuette.dennis@gmail.com Great Bend, KS 67530

-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Stephen Russell Sent: Friday, July 17, 2020 11:06 AM To: profoxtech@leafe.com Subject: [NF] I will .....

Alright, I'm not a priest, but I am a programmer.

Confess to me your programming sins, and I shall absolve you.

-- Stephen Russell Sr. Analyst Ring Container Technology Oakland TN

901.246-0159 cell

--- StripMime Report -- processed MIME parts --- multipart/alternative text/plain (text body -- kept) text/html

---

[excessive quoting removed by server]

I would wager that less than 5% of devs (in VFP anyway) have unit tests in their solution setup.

On 7/21/2020 10:04 AM, Johan Nel wrote:

Ah my child, I have to confess I have never in my complete development career had a plan or unit test done...

On 2020/07/21 15:13, Eric Selje wrote:

...

Forgive me father, for I have started coding without having a plan or even a unit test written first. It's been 51 years since my last confession.

On Sat, Jul 18, 2020 at 1:57 PM Dennis Schuette dennis@cbsds.com wrote:

...

That's such an easy change, I won't even bill you for it.

1 hour of programming, 5 hours of debugging, and 3 customer requested enhancements later, I'm almost done!

Customized Business Services, LLC         (928) 580-6352 Dennis Schuette Primary: dennis@cbsds.com 49 NW 130 Avenue Alternate: Schuette.dennis@gmail.com Great Bend, KS  67530

-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Stephen Russell Sent: Friday, July 17, 2020 11:06 AM To: profoxtech@leafe.com Subject: [NF] I will .....

Alright, I'm not a priest, but I am a programmer.

Confess to me your programming sins, and I shall absolve you.

-- Stephen Russell Sr. Analyst Ring Container Technology Oakland TN

901.246-0159 cell

--- StripMime Report -- processed MIME parts --- multipart/alternative    text/plain (text body -- kept)    text/html

---

[excessive quoting removed by server]

To make an unit test in VFP is as easy as anything: just write your code, highlight it, activate the shortcut (right mouse click), select the option 'Execute the selection'. A very neat and quick solution. Stay healthy, Koen

Op wo 22 jul. 2020 om 02:09 schreef Stephen Russell srussell705@gmail.com:

Why not?

Design by Test. You create your functionality in TESTS and then use those functions in a UI.

On Tue, Jul 21, 2020 at 5:53 PM MB Software Solutions, LLC < mbsoftwaresolutions@mbsoftwaresolutions.com> wrote:

...

I would wager that less than 5% of devs (in VFP anyway) have unit tests in their solution setup.

On 7/21/2020 10:04 AM, Johan Nel wrote:

...

Ah my child, I have to confess I have never in my complete development career had a plan or unit test done...

On 2020/07/21 15:13, Eric Selje wrote:

...

Forgive me father, for I have started coding without having a plan or even a unit test written first. It's been 51 years since my last

confession.

...

...

...

On Sat, Jul 18, 2020 at 1:57 PM Dennis Schuette dennis@cbsds.com wrote:

...

That's such an easy change, I won't even bill you for it.

1 hour of programming, 5 hours of debugging, and 3 customer requested enhancements later, I'm almost done!

Customized Business Services, LLC (928) 580-6352 Dennis Schuette Primary: dennis@cbsds.com 49 NW 130 Avenue Alternate: Schuette.dennis@gmail.com Great Bend, KS 67530

-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Stephen Russell Sent: Friday, July 17, 2020 11:06 AM To: profoxtech@leafe.com Subject: [NF] I will .....

Alright, I'm not a priest, but I am a programmer.

Confess to me your programming sins, and I shall absolve you.

-- Stephen Russell Sr. Analyst Ring Container Technology Oakland TN

901.246-0159 cell

--- StripMime Report -- processed MIME parts ---

multipart/alternative

...

...

...

...

text/plain (text body -- kept) text/html

---

[excessive quoting removed by server]

I may be biased here, having given the Unit Test talk at SW Fox and now maintaining FoxUnit on GitHub, but to me Test-Driven Development is one of those things where I "saw the light". As Stephen says, writing the tests first forces you to think about design first, which always leads to better programs. And w/ FoxMock you can remove all externalities from the tests to ensure it's your code that's getting tested and not its dependencies on other services like SQL Server or other APIs.

Having said that, TDD does work "best" for new development, and many VFP devs are not doing a ton of apps from scratch which is why it may not have caught on. It also works best with logic that's not buried in the UI, and unfortunately a lot of us buried it there (forgive me father). It can work well for existing apps though, and a fairly recent (5 years?) feature of FoxUnit is that it will scan your existing class libs and create a test harness for all of your methods to get you started.

Here's the FoxUnit whitepaper http://saltydogllc.com/wp-content/uploads/Selje_FoxUnit-in-Depth.pdf if anyone's interested.

Eric

On Wed, Jul 22, 2020 at 1:35 AM Christof Wollenhaupt < christof@wollenhaupt.org> wrote:

...

To make an unit test in VFP is as easy as anything: just write your code, highlight it, activate the shortcut (right mouse click), select the option 'Execute the selection'. A very neat and quick solution.

It's even quicker if you use FoxUnit and foxmock. Both are free on VFPX. I've hundreds of unit tests that I can run with a single key stroke that test many different modules of our applications. Writing testable code also tends to lead to a cleaner class design that is more reusable.

-- Christof

--- StripMime Report -- processed MIME parts --- multipart/alternative text/plain (text body -- kept) text/html

---

[excessive quoting removed by server]

Having said that, TDD does work "best" for new development, and many VFP devs are not doing a ton of apps from scratch which is why it may not have caught on. It also works best with logic that's not buried in the UI, and unfortunately a lot of us buried it there (forgive me father).

We have used FoxUnit for our FoxPro DOS based application. That program was certainly not written with unit tests or even classes in mind. But even a procedure with private variables can be a testable unit if you design the interface carefully.

It doesn't make sense to retrospectively create unit test for an existing application, I agree. However, when you modify existing code it's often possible to move the parts that you need to change out of the SCX Click or whatever method into a separate class. There is no need to do this all at once, just when you need to make changes to code anyway.

When code uses functions like MESSAGEBOX(), etc. you can replace those with a simple messagebox or dialog class (such as the one in INTL) and then in your test mock this class. Various tests can then cover multiple paths through the code depending on a simulated choice a user made. You can also assert that certain messages are shown to the user by making a call an expectation in foxmock and then verify those afterwards.

Whenever you go back into it for one reason or another, add a new test for that area you are working in.

If all of your code is in screens or forms, you might be doing it wrong.

On Wed, Jul 22, 2020 at 10:55 AM Eric Selje Eric@saltydogllc.com wrote:

/It doesn't make sense to retrospectively create unit test for an existing application/

Useful for when you're going to make changes and you want to ensure they don't break your existing app, especially for code that you inherited and may not fully understand. That was the impetus behind that feature. Definitely seems backwards though.

Eric

On Wed, Jul 22, 2020 at 8:23 AM Christof Wollenhaupt < christof@wollenhaupt.org> wrote:

...

...

Having said that, TDD does work "best" for new development, and many

VFP

...

...

devs are not doing a ton of apps from scratch which is why it may not

have

...

caught on. It also works best with logic that's not buried in the UI,

and

...

...

unfortunately a lot of us buried it there (forgive me father).

We have used FoxUnit for our FoxPro DOS based application. That program was certainly not written with unit tests or even classes in mind. But

even

...

a procedure with private variables can be a testable unit if you design

the

...

interface carefully.

It doesn't make sense to retrospectively create unit test for an existing application, I agree. However, when you modify existing code it's often possible to move the parts that you need to change out of the SCX Click

or

...

whatever method into a separate class. There is no need to do this all at once, just when you need to make changes to code anyway.

When code uses functions like MESSAGEBOX(), etc. you can replace those with a simple messagebox or dialog class (such as the one in INTL) and

then

...

in your test mock this class. Various tests can then cover multiple paths through the code depending on a simulated choice a user made. You can

also

...

assert that certain messages are shown to the user by making a call an expectation in foxmock and then verify those afterwards.

-- Christof

--- StripMime Report -- processed MIME parts --- multipart/alternative text/plain (text body -- kept) text/html

---

[excessive quoting removed by server]

My UI rarely does any voodoo for making things work. Been that way for almost 20 years now.

Plus with Fox of course the more you keep in PRG files the easier it is to work with source control.

You test success and expected failure.

Your code lives in the business layer/object. In one prg you call all of that functionality one at a time to make sure it works, as expected. If a function receives a date as a parameter, pass in a bad date to validate it doesn't work.

Over the life of your app as changes are made this is an easy way to see if a change made effects anything else.

On Wed, Jul 22, 2020 at 1:35 AM Christof Wollenhaupt < christof@wollenhaupt.org> wrote:

...

To make an unit test in VFP is as easy as anything: just write your code, highlight it, activate the shortcut (right mouse click), select the option 'Execute the selection'. A very neat and quick solution.

It's even quicker if you use FoxUnit and foxmock. Both are free on VFPX. I've hundreds of unit tests that I can run with a single key stroke that test many different modules of our applications. Writing testable code also tends to lead to a cleaner class design that is more reusable.

-- Christof

--- StripMime Report -- processed MIME parts --- multipart/alternative text/plain (text body -- kept) text/html

---

[excessive quoting removed by server]

I still have trouble conceptualizing how to write unit tests for data access.

On Thu, Jul 23, 2020, 11:37 MB Software Solutions, LLC < mbsoftwaresolutions@mbsoftwaresolutions.com> wrote:

I have done it that way before, and it works well. I wrote the DataObj and BizObj first before the UI for those purposes. But alas, those are mere validation and data access classes; those are not Unit Tests, by my definition anyway. Ever since I did this n-tier design after watching Bob Lee's WhilFest presentation in 2003, it's worked out great. It's much easier to connect the UI to those processes. But my comment still stands: I bet less than 5% of VFP devs write unit tests in their apps.

On 7/21/2020 8:09 PM, Stephen Russell wrote:

...

Why not?

Design by Test. You create your functionality in TESTS and then use

those

...

functions in a UI.

On Tue, Jul 21, 2020 at 5:53 PM MB Software Solutions, LLC < mbsoftwaresolutions@mbsoftwaresolutions.com> wrote:

...

I would wager that less than 5% of devs (in VFP anyway) have unit tests in their solution setup.

On 7/21/2020 10:04 AM, Johan Nel wrote:

...

Ah my child, I have to confess I have never in my complete development career had a plan or unit test done...

On 2020/07/21 15:13, Eric Selje wrote:

...

Forgive me father, for I have started coding without having a plan or even a unit test written first. It's been 51 years since my last

confession.

...

...

...

...

On Sat, Jul 18, 2020 at 1:57 PM Dennis Schuette dennis@cbsds.com wrote:

...

That's such an easy change, I won't even bill you for it.

1 hour of programming, 5 hours of debugging, and 3 customer requested enhancements later, I'm almost done!

Customized Business Services, LLC (928) 580-6352 Dennis Schuette Primary: dennis@cbsds.com 49 NW 130 Avenue Alternate: Schuette.dennis@gmail.com Great Bend, KS 67530

-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Stephen Russell Sent: Friday, July 17, 2020 11:06 AM To: profoxtech@leafe.com Subject: [NF] I will .....

Alright, I'm not a priest, but I am a programmer.

Confess to me your programming sins, and I shall absolve you.

-- Stephen Russell Sr. Analyst Ring Container Technology Oakland TN

901.246-0159 cell

--- StripMime Report -- processed MIME parts ---

multipart/alternative

...

...

...

...

...

text/plain (text body -- kept)
text/html

---

[excessive quoting removed by server]

I still have trouble conceptualizing how to write unit tests for data access.

I have a function that reads a table and recreates the same structure as an empty cursor with all indexes, and such. Optionally, it appends the existing content of the table. In my unit test I can then make changes to the cursor.

This covers about 80-90% of the need if you have a common way of opening tables that you can plug into. For test cases, where a cursor is too different from the table for a useful test, I do have test data in a subfolder that I copy into a temporary folder and then use for the test.

For projects that use a more object oriented approach I use foxmock to simulate data. Most times what I really need isn't the actual data access, because I know that these classes work, rather I have to test the code that accesses data. foxmock has a method that returns a scatter object based on a record.

I only see it as testing a connection to a defined data source. You have creds that work for a positive test. You have creds that fail to notify you that no connection was made.

If your function receives params for the actual source you are just changing the params you pass back, or where they are coming back from.

Proving something didn't work helps you catch errors nicely and deal with them.

For my coding style, I have a function that may be overloaded 2-3-+ ways. All of them need to be tested.

On Thu, Jul 23, 2020 at 12:18 PM Garrett Fitzgerald sarekofvulcan@gmail.com wrote:

I still have trouble conceptualizing how to write unit tests for data access.

On Thu, Jul 23, 2020, 11:37 MB Software Solutions, LLC < mbsoftwaresolutions@mbsoftwaresolutions.com> wrote:

...

I have done it that way before, and it works well. I wrote the DataObj and BizObj first before the UI for those purposes. But alas, those are mere validation and data access classes; those are not Unit Tests, by my definition anyway. Ever since I did this n-tier design after watching Bob Lee's WhilFest presentation in 2003, it's worked out great. It's much easier to connect the UI to those processes. But my comment still stands: I bet less than 5% of VFP devs write unit tests in their apps.

On 7/21/2020 8:09 PM, Stephen Russell wrote:

...

Why not?

Design by Test. You create your functionality in TESTS and then use

those

...

functions in a UI.

On Tue, Jul 21, 2020 at 5:53 PM MB Software Solutions, LLC < mbsoftwaresolutions@mbsoftwaresolutions.com> wrote:

...

I would wager that less than 5% of devs (in VFP anyway) have unit

tests

...

...

...

in their solution setup.

On 7/21/2020 10:04 AM, Johan Nel wrote:

...

Ah my child, I have to confess I have never in my complete

development

...

...

...

...

career had a plan or unit test done...

On 2020/07/21 15:13, Eric Selje wrote:

...

Forgive me father, for I have started coding without having a plan

or

...

...

...

...

...

even a unit test written first. It's been 51 years since my last

confession.

...

...

...

...

On Sat, Jul 18, 2020 at 1:57 PM Dennis Schuette dennis@cbsds.com wrote:

> That's such an easy change, I won't even bill you for it. > > 1 hour of programming, 5 hours of debugging, and 3 customer

requested

...

...

...

...

...

> enhancements later, I'm almost done! > > Customized Business Services, LLC (928) 580-6352 > Dennis Schuette Primary: > dennis@cbsds.com > 49 NW 130 Avenue Alternate: > Schuette.dennis@gmail.com > Great Bend, KS 67530 > > -----Original Message----- > From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf

Of

...

...

...

...

...

> Stephen Russell > Sent: Friday, July 17, 2020 11:06 AM > To: profoxtech@leafe.com > Subject: [NF] I will ..... > > Alright, I'm not a priest, but I am a programmer. > > Confess to me your programming sins, and I shall absolve you. > > > > -- > Stephen Russell > Sr. Analyst > Ring Container Technology > Oakland TN > > 901.246-0159 cell > > > --- StripMime Report -- processed MIME parts ---

multipart/alternative

...

...

...

...

> text/plain (text body -- kept) > text/html > --- >

[excessive quoting removed by server]

Pretty much for anything that is repetitive in nature. All apps yes. I have the instances set to not allow homemade sql except for some of our new stuff in R, or my certificate report that passes SQL to include all of the Lot Numbers needed. It is on a separate sql server and operates very slowly if I use a where in with code that executed at the calling server.

Why would you NOT use sprocs is my #1 question?

On Thu, Jul 23, 2020 at 5:30 PM MB Software Solutions, LLC < mbsoftwaresolutions@mbsoftwaresolutions.com> wrote:

Stephen -- Are you still using stored procedures for all your CRUD?

On 7/23/2020 5:54 PM, Stephen Russell wrote:

...

I only see it as testing a connection to a defined data source. You have creds that work for a positive test. You have creds that fail to notify you that no connection was made.

If your function receives params for the actual source you are just changing the params you pass back, or where they are coming back from.

Proving something didn't work helps you catch errors nicely and deal with them.

For my coding style, I have a function that may be overloaded 2-3-+ ways. All of them need to be tested.

On Thu, Jul 23, 2020 at 12:18 PM Garrett Fitzgerald <

sarekofvulcan@gmail.com>

...

wrote:

...

I still have trouble conceptualizing how to write unit tests for data access.

On Thu, Jul 23, 2020, 11:37 MB Software Solutions, LLC < mbsoftwaresolutions@mbsoftwaresolutions.com> wrote:

...

I have done it that way before, and it works well. I wrote the DataObj and BizObj first before the UI for those purposes. But alas, those are mere validation and data access classes; those are not Unit Tests, by

my

...

...

...

definition anyway. Ever since I did this n-tier design after watching Bob Lee's WhilFest presentation in 2003, it's worked out great. It's much easier to connect the UI to those processes. But my comment still stands: I bet less than 5% of VFP devs write unit tests in their apps.

On 7/21/2020 8:09 PM, Stephen Russell wrote:

...

Why not?

Design by Test. You create your functionality in TESTS and then use

those

...

functions in a UI.

On Tue, Jul 21, 2020 at 5:53 PM MB Software Solutions, LLC < mbsoftwaresolutions@mbsoftwaresolutions.com> wrote:

...

I would wager that less than 5% of devs (in VFP anyway) have unit

tests

...

...

...

in their solution setup.

On 7/21/2020 10:04 AM, Johan Nel wrote: > Ah my child, I have to confess I have never in my complete

development

...

...

...

> career had a plan or unit test done... > > On 2020/07/21 15:13, Eric Selje wrote: >> Forgive me father, for I have started coding without having a plan

or

...

...

...

>> even >> a unit test written first. It's been 51 years since my last

confession.

...

...

>> On Sat, Jul 18, 2020 at 1:57 PM Dennis Schuette dennis@cbsds.com >> wrote: >> >>> That's such an easy change, I won't even bill you for it. >>> >>> 1 hour of programming, 5 hours of debugging, and 3 customer

requested

...

...

...

>>> enhancements later, I'm almost done! >>> >>> Customized Business Services, LLC (928) 580-6352 >>> Dennis Schuette Primary: >>> dennis@cbsds.com >>> 49 NW 130 Avenue Alternate: >>> Schuette.dennis@gmail.com >>> Great Bend, KS 67530 >>> >>> -----Original Message----- >>> From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf

Of

...

...

...

>>> Stephen Russell >>> Sent: Friday, July 17, 2020 11:06 AM >>> To: profoxtech@leafe.com >>> Subject: [NF] I will ..... >>> >>> Alright, I'm not a priest, but I am a programmer. >>> >>> Confess to me your programming sins, and I shall absolve you. >>> >>> >>> >>> -- >>> Stephen Russell >>> Sr. Analyst >>> Ring Container Technology >>> Oakland TN >>> >>> 901.246-0159 cell >>> >>> >>> --- StripMime Report -- processed MIME parts ---

multipart/alternative

...

...

>>> text/plain (text body -- kept) >>> text/html >>> --- >>>

[excessive quoting removed by server]

There are performance implications to using SPs, at least in MSSQL.

--

rk

-----Original Message----- From: ProfoxTech profoxtech-bounces@leafe.com On Behalf Of MB Software Solutions, LLC Sent: Thursday, July 23, 2020 10:27 PM To: profoxtech@leafe.com Subject: Re: Unit tests (was Re: [NF] I will .....)

On 7/23/2020 8:07 PM, Stephen Russell wrote:

Pretty much for anything that is repetitive in nature. All apps yes. I have the instances set to not allow homemade sql except for some of our new stuff in R, or my certificate report that passes SQL to include all of the Lot Numbers needed. It is on a separate sql server and operates very slowly if I use a where in with code that executed at the calling server.

Why would you NOT use sprocs is my #1 question?

Years ago there was the debate as to whether you put all the logic into your backend database or DataObject class...I went for the latter.  Gave me easier portability if I ever needed it.  (And actually, I did...I went from VFP backends to MySQL/MariaDB 15 years ago.  Required VERY LITTLE code changes!)  Now that doesn't mean I don't use stored procedure...I do!  I just don't use them for basic INSERT/UPDATE/DELETE statements.  I do use triggers though too.

-- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

_______________________________________________ Post Messages to: ProFox@leafe.com Subscription Maintenance: https://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: https://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: https://leafe.com/archives This message: https://leafe.com/archives/byMID/a1f6a03d-88f2-0cd8-6c9e-0280eb5ff096@mbsoft... ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious. Report [OT] Abuse: http://leafe.com/reportAbuse/a1f6a03d-88f2-0cd8-6c9e-0280eb5ff096@mbsoftware...

With MSSQL it's all about execution plans and statistics. An SP is a known quantity whereas SPT queries have to be evaluated each time they are run. Regardless, a poorly written SP or one with a bad plan in the cache can still perform badly. As Uncle Ted always tells us, you have to test in your environment with your data.

--

rk

-----Original Message----- From: ProfoxTech profoxtech-bounces@leafe.com On Behalf Of MB Software Solutions, LLC Sent: Friday, July 24, 2020 9:30 AM To: profoxtech@leafe.com Subject: Re: Unit tests (was Re: [NF] I will .....)

I always thought stored procedures were faster??

On 7/24/2020 8:43 AM, Richard Kaye wrote:

There are performance implications to using SPs, at least in MSSQL.

--

rk

-----Original Message----- From: ProfoxTech profoxtech-bounces@leafe.com On Behalf Of MB Software Solutions, LLC Sent: Thursday, July 23, 2020 10:27 PM To: profoxtech@leafe.com Subject: Re: Unit tests (was Re: [NF] I will .....)

On 7/23/2020 8:07 PM, Stephen Russell wrote:

...

Pretty much for anything that is repetitive in nature. All apps yes. I have the instances set to not allow homemade sql except for some of our new stuff in R, or my certificate report that passes SQL to include all of the Lot Numbers needed. It is on a separate sql server and operates very slowly if I use a where in with code that executed at the calling server.

Why would you NOT use sprocs is my #1 question?

Years ago there was the debate as to whether you put all the logic into your backend database or DataObject class...I went for the latter.  Gave me easier portability if I ever needed it.  (And actually, I did...I went from VFP backends to MySQL/MariaDB 15 years ago.  Required VERY LITTLE code changes!)  Now that doesn't mean I don't use stored procedure...I do!  I just don't use them for basic INSERT/UPDATE/DELETE statements.  I do use triggers though too.

-- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

[excessive quoting removed by server]

_______________________________________________ Post Messages to: ProFox@leafe.com Subscription Maintenance: https://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: https://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: https://leafe.com/archives This message: https://leafe.com/archives/byMID/87ebec4c-a323-0f86-829b-a98c3b49a020@mbsoft... ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious. Report [OT] Abuse: http://leafe.com/reportAbuse/87ebec4c-a323-0f86-829b-a98c3b49a020@mbsoftware...

I'll bite. If you don't use sprocs for standard CRUD operations, why do you need them? Do you work with a great deal of 4th normal data that the joining of the same tables over and over is easier in a sproc? Or do you have a process like EOM where you are doing repetitive things to data tables? Maybe it is good for dealing with data in separate systems/environments that allow you to get warehousing data from WHS and then issue pick tickets and truck lists to move it all?

My most used sproc gets shipping data from the ERP and pull specifications from of BOM system for each item, and then averages metrics from our test system by item by lot giving the customer a Certificate of Analysis. I pull AD data to determine who are the managers at that plant for every truckload we ship.

On Thu, Jul 23, 2020 at 9:27 PM MB Software Solutions, LLC < mbsoftwaresolutions@mbsoftwaresolutions.com> wrote:

On 7/23/2020 8:07 PM, Stephen Russell wrote:

...

Pretty much for anything that is repetitive in nature. All apps yes. I have the instances set to not allow homemade sql except for some of our

new

...

stuff in R, or my certificate report that passes SQL to include all of

the

...

Lot Numbers needed. It is on a separate sql server and operates very slowly if I use a where in with code that executed at the calling server.

Why would you NOT use sprocs is my #1 question?

Years ago there was the debate as to whether you put all the logic into your backend database or DataObject class...I went for the latter. Gave me easier portability if I ever needed it. (And actually, I did...I went from VFP backends to MySQL/MariaDB 15 years ago. Required VERY LITTLE code changes!) Now that doesn't mean I don't use stored procedure...I do! I just don't use them for basic INSERT/UPDATE/DELETE statements. I do use triggers though too.

-- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

[excessive quoting removed by server]

What I have seen from TDD is the following: -  Lazy behavior - developer types (or the 'testing group') run off to write a lot of 'test code' instead of asking the hard questions of stakeholders - pushing on things that are not solid, etc (TDD generally has it's own 'syntax' like an additional programming language). - Since it is it's own syntax, you are essentially writing additional code. Not nearly as much code as the actual "function" - but it is separate and distinct. This means if that "difficult" requirement finally gets resolved and things are different than expected (because of the upfront lazy thinking), you have to go back and change both the "functional" and "test" code that was incorrect. - After about a lot test cases are created, maybe 1,000 (many of them performing things like 1+1=2, right?) the team expectations start to get damaged. E.g. a new Story (requirement/function) is completed and run through the test definitions. 999 tests passed, 1 test failed. Most 'non-developers' on the team think things are still going great - but it just so happens that 1 thing that failed was solely related to the one new thing released. It's a critical function, the software cannot proceed without it. But... but... 99.9% of everything is working right? - Due to the encouraged lazy thinking and the 'number of tests' dilution of understanding, the actual 'test programming' becomes worse over time (on big projects). And if some nutcase happens to throw "Sarbanes Oxley" at the project (separation of roles), then you have people writing test code devoid of understanding of the developers approach. That sounds good on the surface, but in my experience such failures were not caused by the 'business need'. After the failure, the tester and developer talk, and usually the tester changes their code to make the test case work (the developer had a better handle on the requirement). That's time spent on making TDD work, not implementing business requirements. - If there is a separate testing group, TDD encourages 'magic requirement creation' - a requirement appeared out of thin air, not requested by the stakeholders/project owner. That is scope creep, plain and simple. The sad thing is instead of bubbling such things up to get a ruling, inexperienced developers often just go off and burn more time, writing more code to meet the 'magic requirement.' Note that this issue isn't a direct failing of TDD, but if there is an independent testing group in charge of the TDD, then it empowers them, I'd say encourages them, to bleed the project this way. - In summary, with TDD, a lot more time is spent accomplishing the end result.

Clearly I'm focusing on the negative to give some balance. TDD does make you 'think' about things. But really, you should have been 'thinking' about those things already.

As an allegory I'll bring in the concept of Agile development. What I have found is the main benefit of Agile is not the SCRUM, Kanban, just-in-time-requirements, ability to change priority mid-stream, etc. The benefit of Agile is building an actual 'team' that includes EVERYONE, testers, stakeholders, developers... everyone. As the project goes along it becomes easier and easier to identify those that are not really part of the team. You eject those people or make sure everyone knows the project is at risk because they are there (after the appropriate coaching, pleading, etc, to try to get them to change their behavior).

So, Agile gives a way to get to what should have already existed - you just get there sideways instead of straight-away.

Likewise, TDD helps get done what should have been done anyway - but kinda sideways.

For me, I write software 'defensively' by nature - decades of coding and the need to maintain it for those decades drove me there. So my forays into TDD have only led to increased time with no significant benefit in results.

But across the spectrum of software languages, businesses, so-called standards, best(worst) practices, individual agendas, personal 'skill level', office politics, muddled technologies, and outright lies in our industry, you do what you can to accomplish your goals. So by all means, use TDD if you enjoy it or think it forces discipline in a weak area. But it is most certainly not a silver bullet that kills all the baddie-werewolves we face in our industry.

-Charlie

On 7/23/2020 1:17 PM, Garrett Fitzgerald wrote:

I still have trouble conceptualizing how to write unit tests for data access.

On Thu, Jul 23, 2020, 11:37 MB Software Solutions, LLC < mbsoftwaresolutions@mbsoftwaresolutions.com> wrote:

...

I have done it that way before, and it works well. I wrote the DataObj and BizObj first before the UI for those purposes. But alas, those are

...

This is an actual test in my code:

[TestMethod] public void custItemView() { String item = "351000287"; String VenItem = EFData.GetCustomerPartFromView(item); Assert.IsTrue(VenItem.Length > 0); }

My function has a view of all items in our cross-reference tables. Is that found and what is their item number for it. I assert that it will be found, and to verify it was, the length of the string has to have some data.

On Fri, Jul 24, 2020 at 8:20 AM Alan Bourke alanpbourke@fastmail.fm wrote:

...

I still have trouble conceptualizing how to write unit tests for data access.

That's an integration test, really, not a unit test.

What I do is set up data sets of VFP tables or SQL Server and then zip\unzip the one that applies to the test, as part of the test.

-- Alan Bourke alanpbourke (at) fastmail (dot) fm

[excessive quoting removed by server]

Apostate! Heathen!

On Tue, Jul 21, 2020 at 11:19 AM Bill Anderson billand88@gmail.com wrote:

As a developer once (dramatically, suspiciously looks left, looks right) I tried using tabs as an indentation...

Please forgive me

Bill Anderson

On Tue, Jul 21, 2020 at 6:15 AM Eric Selje Eric@saltydogllc.com wrote:

...

Forgive me father, for I have started coding without having a plan or

even

...

a unit test written first. It's been 51 years since my last confession.

On Sat, Jul 18, 2020 at 1:57 PM Dennis Schuette dennis@cbsds.com

wrote:

...

...

That's such an easy change, I won't even bill you for it.

1 hour of programming, 5 hours of debugging, and 3 customer requested enhancements later, I'm almost done!

Customized Business Services, LLC (928) 580-6352 Dennis Schuette Primary: dennis@cbsds.com 49 NW 130 Avenue Alternate: Schuette.dennis@gmail.com Great Bend, KS 67530

-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Stephen Russell Sent: Friday, July 17, 2020 11:06 AM To: profoxtech@leafe.com Subject: [NF] I will .....

Alright, I'm not a priest, but I am a programmer.

Confess to me your programming sins, and I shall absolve you.

-- Stephen Russell Sr. Analyst Ring Container Technology Oakland TN

901.246-0159 cell

--- StripMime Report -- processed MIME parts --- multipart/alternative text/plain (text body -- kept) text/html

---

[excessive quoting removed by server]