Test Generator 2.4.20

01What this actually is

A commercial computer-based testing / assessment suite built by Fain & Company (testshop.com). It spans three generations of technology stacked on one shared database schema: a Visual Basic 6 desktop authoring & delivery product, a Java servlet web tier that serves the same tests over HTTP, and an MFC C++ kiosk browser that locks Windows down while a candidate sits an exam.

02The stack, end to end

Three client tiers, one schema. The desktop tier and the web tier are independent implementations that read and write the same tables — the Java code re-implements the VB6 domain model rather than calling into it.

03Desktop tier — VB6

The desktop product is 20+ executables built from 39 .vbp manifests, all sharing one library directory. TestGen.vbp alone pulls in 127 source members.

Shippable executables

Tools/ additionally contains 11 satellite VB projects: dbcheck, dbexport, dbselect, dbup2d8, tgup2d8, organizeusers, removelock, resetPass, getVersion, tgauth, tgauthenticode, plus dbconvert in four engine-specific flavours.

The main console is built from tab modules

Rather than one monolithic MDI form, TestGen.exe composes 12 FCOTG_* ActiveX UserControls, one per functional area — this is the product's real feature map:

Six more generic controls (ucRTFEditor, ucEmailEditor, ucScoreMessage, ucDateControl, ucPrintSpecial, classes) provide reusable editing widgets.

04Data tier

One schema, portable across six engines, reached through a single façade class.

Engine portability

Shared_Modules/modTGEnums.bas declares the supported backends, and CDAC_ADO.cls emits a different connection string for each:

' modTGEnums.bas
Public Enum eDatabaseEngineType
    eDT_Access2000 = 1
    eDT_MSSQL2000  = 5
    eDT_MySQL4     = 10
    eDT_Postgres7  = 15
    eDT_Firebird   = 20
    eDT_Oracle     = 25
End Enum

Five connections, not one

CDAC_ADO holds five independent ADO connections — pmoTGCon, pmoQBCon, pmoMediaCon, pmoEssayCon, pmoCustomCon. Under Access these map to four physical files (TestGen.MDB, QBank.MDB, Media.MDB, Essay.MDB); under any server engine all five collapse onto one database name. The split is a legacy of the Jet file-size ceiling, carried forward as a logical partition.

Configuration lives in the registry

' modConstants.bas
Public Const FCOTG_REG_ROOT = "SOFTWARE\FCO\Test Generator II"

Server, port, database name, username and password are all read from that key. Credentials are stored Blowfish-encrypted and decrypted at startup with a key assembled at runtime from character arithmetic (convertToBinary3(64) and friends) — obfuscation, not key management.

Core tables

The canonical DDL is generated in code, once per engine, by Shared_Modules/ddl_mssql.cls and ddl_mysql.cls — 26 CREATE TABLE statements in the SQL Server generator, 27 in the MySQL one.

Question types

Q_TYPE is a free-text column; the authoritative list is enumerated in the Java entity Question.java, which maps each display name to a short code:

Test behaviour is heavily parameterised

• Test type — Test, Survey, Test-followed-by-Survey, or Question Bank (TGTestType).
• Bank draw modes — six strategies in TGTestBankTypes: all questions, n random questions, n random subjects, n per subject, n subjects × m questions, or a per-subject count map.
• Retakes — none / unlimited / limited, gated on circumstance (some blank, all answered, either, or not-passed) and on what the retake starts from (old answers kept, cleared, or a fresh draw).
• Pass criteria — percentage, or "all sections passed" (TGTestPassFailOption).
• Messaging — before/after hooks at test or section scope, typed as tester e-mail, general message, navigation, or scheduled e-mail.

05Web tier — Java on Tomcat

A servlet application, deployed as WARs, that re-implements test delivery over HTTP against the same schema. Deployment notes reference jakarta-tomcat-4.1.30 fronted by Apache via mod_jk.

The exam flow, read off the servlet names

LoginServlet / DualLoginServlet / SSOLogin / ForgetPassword / ResetPassword
   → TestListServlet → ViewDisclaimerServlet → BeginTestMessageServlet
   → BeginTestServlet → BeginSectionMessageServlet
       → LoadQuestionServlet / DispQuestionServlet
       → PointClickServlet · ViewQuestionMediaServlet · MediaBankServlet
       → ShowTimedServlet / ShowSectionTimedServlet
       → SectionTimeUpServlet / TimeUpServlet / SectionCriteriaEndServlet
   → EndSectionMessageServlet → EndTestMessageServlet
   → SummaryListServlet · TestReportServlet · ViewTakerSummaryServlet
   → CertificateServlet
Side channels: FeedBackServlet · UserFBServlet · OutEnrollServlet ·
               UnlockServlet · SCORMLauncher · FlushCacheServlet

A hand-rolled template engine, used for HTML and SQL

com.fco.tg.base.html.Tmpl implements an HTML::Template dialect — Var, If, Unless, Loop, Include, Conditional. The same parser drives 62 .tmpl page templates and 138 .sql query templates. Queries are assembled by string substitution with an escaping hint:

-- templates/common/sql/taker/…
select ta_password, ta_email
from takers
where ta_username = '<tmpl_var escape=sql name=ta_username>'
  and ta_email    = '<tmpl_var escape=sql name=ta_email>'

Safety therefore depends entirely on every author remembering escape=sql. There is no prepared-statement layer; SqlRunner executes the rendered string.

Runtime dependencies

31 jars are vendored under common/lib. The interesting ones:

Authentication

Three modes are declared in eAuthenticationType: Local, LDAP, WINNT. docs/ldap.txt documents Active Directory binding through the Global Catalog on port 3268, configured by TGAuth.exe, with the rule that the user must also exist in TG — AD verifies the password, TG owns authorisation. docs/sso.txt covers IIS integrated auth forwarded to Tomcat over the jk2 connector with tomcatAuthentication=false.

06SecureTG — the kiosk layer

An MFC single-document application whose entire view is an embedded Internet Explorer IWebBrowser2 control pointed at the web tester. Its job is to make the Windows desktop unusable for the duration of the exam.

How the server knows the browser is SecureTG

This is the one genuinely clever seam between the C++ and Java halves, and it is worth reading closely because it is also the weakest link.

SecureTG builds two strings from character arithmetic so they never appear as literals in the binary, MD5s each, and injects them as request headers:

// SecureTGView.cpp — reconstructed
key                = MD5("TGAdmin");   // built as 65+19, 65+6, 65+0, 65+35, …
secure_user_agent  = MD5("SecureTG");  // built as 65+18, 65+36, 65+34, 65+52, …
header = "X-Tester: " + key + "\r\nUser-Agent: " + secure_user_agent + "\r\nAccept-Language: en-us";

The header is re-attached on every BeforeNavigate2, so it survives form posts inside the exam. On the other side, tester/LoginServlet.java checks it:

private static boolean verifyKeys(String useragent, String key) {
    // key = TGAdmin, useragent = SecureTG
    if (MD5.hash("TGAdmin").equals(key) && MD5.hash("SecureTG").equals(useragent))
        …
}

A companion ActiveX control (web/secureTG/activex to pop securetg/source/activex/stglauncher.vbp) exists so a web page can launch the kiosk directly from the browser.

07The external/ archive

A vendored dependency store, one directory per supplier — 75 DLLs and 20 OCXs. Its README.txt states the policy plainly: "if we have the source code, we'll keep it here, and build it ourselves. if the supplier will only give us compiled versions, we'll keep the binaries here."

08Build, packaging and release

Versioning is manual

docs/versioning.txt, in full: "edit the .vbp file by incrementing the RevisionVer= line. duplicate the changes to that version in the version.txt file found in the same projects folder." There is no build server — output/ is the (empty) drop directory that every .vbp points at via Path32=..\output.

Installers are Inno Setup

tg2setup/ holds 11 installer definitions — TestGen, Tester, ST, tgdemo, tgscan, tgup2d8, equation, scorm12, dbexport, and four dbconv* variants — each a thin .iss that includes five shared fragments from tg2setup/common/. Testgen.iss ships the VB6 runtime into {sys} with regserver, drops the eight executables, seeds the clean Access databases from Clean/ with onlyifdoesntexist, and installs the .rpt report set (40 report definitions live in the tree, 38 of them under other_development/reports).

Client auto-update runs through the database

This is the most unusual mechanism in the codebase. sTester.exe / sTestGen.exe are stubs that, before launching the real application:

select filename, create_date from updatebin
 where for_tg = true and create_date > <last update from registry>
 order by create_date desc

If rows come back, the launcher runs its update form to pull the new binaries out of the database, then walks a second query for rows flagged self_register and calls RegisterServer on each DLL/OCX. An administrator upgrades a LAN of clients by inserting rows into a table — no share, no MSI, no push agent.

Stand-alone (disconnected) delivery

docs/st-spec.html specifies the offline product in detail: install by web download, CD or "a set of 4 floppy disks"; tests arrive as self-extracting installers that locate and patch an existing ST; results are exported as an encrypted .MDB named LastName FirstName - TestName.MDB and returned to HQ for import. The spec is candid about its own limits — "Currently there is no procedure in place to ensure end users have not cheated."

Documentation set

docs/ carries 20+ written specs and notes — st-spec.html, lock-spec.html, install-spec.html, uninstall-spec.html, tester-login-spec.html, import-scores-spec.html, corrupt-data-spec.txt, access-security.txt, naming-spec.txt, doc-strategy.txt, an architecture.vsd Visio diagram, plus a 963-line changelog.txt keyed to CVS tags FCO-TestGen-B0 onward. Help was authored in RoboHelp as WinHelp, with a documented intent to move to HTML Help "for TG 3.0".

09Assessment

Where to look first