dcsimg
Results 1 to 17 of 17

Thread: [RESOLVED] Best Practices -- Code Testing

  1. #1

    Thread Starter
    Hyperactive Member
    Join Date
    Feb 2017
    Posts
    409

    Resolved [RESOLVED] Best Practices -- Code Testing

    I have a large program which uses many tables within a database. Periodically, I wish to do testing with the same
    data contained and updated in these tables AT THE SAME TIME this program is live on the same system.
    Consequently, any changes made in the test program will update the tables being used while live.

    Question:
    What is the easiest, best, or better alternative way to deal with this issue?

  2. #2
    Frenzied Member PlausiblyDamp's Avatar
    Join Date
    Dec 2016
    Location
    Newport, UK
    Posts
    1,081

    Re: Best Practices -- Code Testing

    Quote Originally Posted by vb6forever View Post
    I have a large program which uses many tables within a database. Periodically, I wish to do testing with the same
    data contained and updated in these tables AT THE SAME TIME this program is live on the same system.
    Consequently, any changes made in the test program will update the tables being used while live.

    Question:
    What is the easiest, best, or better alternative way to deal with this issue?
    I would say the best way is to not do this, running test programs against a live database is just asking for trouble. Could you not simply take a backup of the live database and restore it to another server in a proper test environment?

  3. #3
    Member
    Join Date
    May 2017
    Posts
    59

    Re: Best Practices -- Code Testing

    Hi. Maybe I'm misunderstanding the question, but...

    Any use of code that isn't already tested to 'high confidence' on active live data isn't testing - it's a strong bet you'll no longer be employed to deal with that data when it gets destroyed.

    The standard rule is - never use alpha or beta releases on a production system.

  4. #4
    PowerPoster
    Join Date
    Feb 2012
    Location
    West Virginia
    Posts
    12,895

    Re: Best Practices -- Code Testing

    Yep, never use the live db for testing.
    What I usually do is use a different connection string when testing and that is pointed to a different DB which if needed will be an exact copy of the current live db. I never target the live db until I am reasonably sure the code works and even then I recommend a backup of the db just in case I missed something in my testing.

  5. #5
    Hyperactive Member
    Join Date
    Feb 2019
    Posts
    382

    Re: Best Practices -- Code Testing

    Use this function to test if the app is running in the IDE, and then use an alternate connection string to a test DB:

    Code:
    Public Function IsInIDE() As Boolean
        Debug.Assert Not CheckIDE(IsInIDE)
    End Function
    
    Private Function CheckIDE(b As Boolean) As Boolean
         b = True
    End Function
    
    Private Sub Form_Load()
         MsgBox IsInIDE()
    End Sub

  6. #6
    Frenzied Member gibra's Avatar
    Join Date
    Oct 2009
    Location
    ITALY
    Posts
    1,661

    Re: Best Practices -- Code Testing

    Quote Originally Posted by qvb6 View Post
    Use this function to test if the app is running in the IDE,
    Also, you can use LogMode property of App object:
    Code:
    If App.LogMode = 0 Then
        MsgBox "Is IDE"
    ElseIf App.LogMode = 1 Then
        MsgBox "Is Exe"
    End If

  7. #7

    Thread Starter
    Hyperactive Member
    Join Date
    Feb 2017
    Posts
    409

    Re: Best Practices -- Code Testing

    Thanks all for input.
    SO the general consensus is NOT to run tests on live DBs and use an alternative (copy) DB.
    Thinking out loud one could have a switch for testing, which invoked would make a copy of the Live DB,
    and force all writes to be made to both the Original DB and the Copy DB.
    The Test Program (copy of original) could then be set to use the Copy DB Only.

  8. #8
    Frenzied Member gibra's Avatar
    Join Date
    Oct 2009
    Location
    ITALY
    Posts
    1,661

    Re: [RESOLVED] Best Practices -- Code Testing

    I would avoid using a different program, because in the case of non-aligned changes you may get different behaviors.
    The program must always be the same, just need a simple MsgBox at startup (i.e. on the Main sub on a BAS module) to choose database:
    Code:
    Pubic Sub Main()
        Dim sDataBase As String 
        sDataBase = "MyDatabase"
        If App.LogMode = 0 Then ' only in IDE
            If MsgBox("Do you want to use the TEST database?", vbYesNo) = vbYes Then
                sDataBase = sDataBase & "Test"
            End If
        End If
        ' code to open database
    End Sub

  9. #9

    Thread Starter
    Hyperactive Member
    Join Date
    Feb 2017
    Posts
    409

    Re: [RESOLVED] Best Practices -- Code Testing

    gibra:
    Thanks for followup. Your suggestion is a better / easier solution.

  10. #10
    Frenzied Member PlausiblyDamp's Avatar
    Join Date
    Dec 2016
    Location
    Newport, UK
    Posts
    1,081

    Re: [RESOLVED] Best Practices -- Code Testing

    Quote Originally Posted by gibra View Post
    I would avoid using a different program, because in the case of non-aligned changes you may get different behaviors.
    The program must always be the same, just need a simple MsgBox at startup (i.e. on the Main sub on a BAS module) to choose database:
    Code:
    Pubic Sub Main()
        Dim sDataBase As String 
        sDataBase = "MyDatabase"
        If App.LogMode = 0 Then ' only in IDE
            If MsgBox("Do you want to use the TEST database?", vbYesNo) = vbYes Then
                sDataBase = sDataBase & "Test"
            End If
        End If
        ' code to open database
    End Sub
    Might be easier and less confusing for a user of the application if this was controlled externally - reg key, config file or similar. That way there is no chance of a user (or tester) accidentally pointing the app to the wrong version.

  11. #11
    PowerPoster techgnome's Avatar
    Join Date
    May 2002
    Posts
    32,413

    Re: [RESOLVED] Best Practices -- Code Testing

    Using an ini or a config file is usually how I've seen it done... and there's typically 3-4 databases/envoronments .. Dev, Testing(QA), Staging, Production.
    Dev - Development - should be self explanatory, it's the developer's sandbox.
    Testing/QA - this is where the changes/updates are then applied after the developer is done tinkering with things and it's tested.
    Staging - Sometimes also known as UAT or or UT - User Acceptance Testing or User Testing - This is where the users get their hands on it and have a chance to take it for a test drive BEFORE it's applied to production. It's also a chance for developers or ProdOps to have a moment to test the deployment scripts/methods before it's deployed for real.
    Production - Again, should be self explanatory. This is the live system.

    In an ideal situation, that's what you' end up with at a minimum. In our environment, we actually have two additional, one of which is a copy of production, sans live data, so that when something goes wrong, we have a place to replicate the issue sing the same version of the software. I forget what the sixth environment is for. I think it's also acopy of prod for QA for patching purposes. But I'm not sure, it wasn't one I used.

    -tg
    * I don't respond to private (PM) requests for help. It's not conducive to the general learning of others.*
    * I also don't respond to friend requests. Save a few bits and don't bother. I'll just end up rejecting anyways.*
    * How to get EFFECTIVE help: The Hitchhiker's Guide to Getting Help at VBF - Removing eels from your hovercraft *
    * How to Use Parameters * Create Disconnected ADO Recordset Clones * Set your VB6 ActiveX Compatibility * Get rid of those pesky VB Line Numbers * I swear I saved my data, where'd it run off to??? *

  12. #12
    Frenzied Member
    Join Date
    Dec 2014
    Location
    VB6 dinosaur land
    Posts
    1,169

    Re: [RESOLVED] Best Practices -- Code Testing

    I'd never use an option that must be selected every time. I have used either config file or conditional compilation statements.

    Code:
    #Const UsingDev = True
    ...
    #If UsingDev Then
        ConnStr = "connection string to Dev server"
    #Else
        ConnStr = "connection string to Prod server"
    #End If
    So compile to use Dev and do all your testing. Once done testing, set to False and recompile. This assumes Dev is identical to Prod, which it should be as far as all relevant objects at least.

  13. #13

    Thread Starter
    Hyperactive Member
    Join Date
    Feb 2017
    Posts
    409

    Re: [RESOLVED] Best Practices -- Code Testing

    I took gibra's suggestion (#8) as just emphasizing a simple way to invoke an alternate DB,
    not necessarily be in Sub Main.
    Follow on posts are a bit more pointed.
    Thanks to all for input.

    ---------
    topshot
    ---------
    I use conditional compilation for trace purpose and works well.
    Would be an easy way to invoke copy writing to Test DB.
    Last edited by vb6forever; May 22nd, 2019 at 08:59 AM.

  14. #14
    Frenzied Member gibra's Avatar
    Join Date
    Oct 2009
    Location
    ITALY
    Posts
    1,661

    Re: [RESOLVED] Best Practices -- Code Testing

    Quote Originally Posted by PlausiblyDamp View Post
    Might be easier and less confusing for a user
    No. This is for developer ONLY.

  15. #15
    PowerPoster
    Join Date
    Feb 2006
    Posts
    20,424

    Re: [RESOLVED] Best Practices -- Code Testing

    How To Use Data Link Files with ADO

    In most current versions of Windows there is no option in Shell32's configuration to create a new blank UDL but you can just make a text file and rename it from .TXT to .UDL and then you can configure it.

    Your program can use the UDL instead of an explicit connection string, making it easy to swap production and test connections.

  16. #16

    Thread Starter
    Hyperactive Member
    Join Date
    Feb 2017
    Posts
    409

    Re: [RESOLVED] Best Practices -- Code Testing

    I still use and prefer DAO, but link should help others.

  17. #17
    Hyperactive Member
    Join Date
    Mar 2018
    Posts
    318

    Re: [RESOLVED] Best Practices -- Code Testing

    Quote Originally Posted by dilettante View Post
    In most current versions of Windows there is no option in Shell32's configuration to create a new blank UDL but you can just make a text file and rename it from .TXT to .UDL and then you can configure it
    Also a great way to test connectivity. Some IT people see an error and our program and assume is has to be a problem we need to fix. With this tool, you can simply say "If microsoft's tool can't connect to the database, I'm not going to be able to connect either".

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Featured


Click Here to Expand Forum to Full Width