![]() So i bite the bullet, read a book and started to migrate my repositories.Īnd I do not regret, here are a few cases where Git made my life easier: Following other teams work flows based in advanced branch management, i realized that Git could improve my software development efforts. Initially, just to fetch the code and, eventually, to send patches, or better, do pull requests. With the time, i started to use Git to interact with a couple of GitHub hosted projects. A system designed for distributed development would not improve over what Subversion offers for an "one man" work flow. I'm also a adept of "If it ain't broke, don't fix it" philosophy so i did not bother to change the source code management software even with all the fuzz around Git. It's not by chance that i bought not one, but two licenses from SmartSVN. Since at least 2005, when FreePascal migrated to SVN, i've been using it to manage my own projects or projects that i collaborate. I consider myself a seasoned Subversion user. ![]() In a way that i foresee using this technique for testing other projects, not only third party specifications.īTW: the test runner source code can be found here While took me some time to understand the FPTest/DUnit2 source code, the solution ended simpler and clearer than i think earlier. With this i get a comprehensive test suite that allows to effectively drive the development. In ExecuteTests, the assertions (called in the specification tests) are executed one by one. Procedure TJSONSchemaTestProc.ExecuteTests ĮxecuteTest(SchemaData, TestsData.Objects) ValidateResult := ValidateJSON(TestData.Elements, SchemaData) Procedure TJSONSchemaTestProc.ExecuteTest(SchemaData, TestData: TJSONObject) ĭescription := TestData.Get('description', '') A not published method (ExecuteTests) is registered with the description of the test as name. Inherited '', Data.Get('description', 'jsonschema-test')) Ī TJSONObject with the test specification is passed in constructor. Procedure ExecuteTest(SchemaData, TestData: TJSONObject) Ĭonstructor TJSONSchemaTestProc.Create(Data: TJSONObject) The key is to subclass TTestProc and properly instantiate it. With the confidence that should exist a better solution, i digged into FPTest source code (a freepascal port of DUnit2) looking how i could have the best of two worlds, data driven dynamic tests with the granularity of handcraft tests.įortunately, i've got a way. To overcome this issue is possible to aggregate tests in one big test case, e.g., a unique test case for JSON Schema type rule, instead of creating one test case for each test description. While it works, this approach has the drawback of the generic method name that would clutter the test runner output with meaningless information. An instance of this class is created for each test, passing the appropriate data. A quick search lead me to the solution of creating a custom TTestCase class with a published method (named generically as Run) that implements the test. So, i looked a way to create the tests dynamically reading directly the JSON files. I could write a program to convert the JSON specification to pascal units with the tests cases like i've done with mustache spec, but is far from optimal approach, imposing the need to recreate the test application each time a change is done in the spec. It's comprised of JSON files describing the specifications for each rule a validator must check. The JSON Schema organization maintains a language agnostic test suite. Given the personal need of a JSON Schema validator implemented in pascal, i decided to write one and, naturally, with a test driven approach. In fact, in one recent mid sized project, i created the tests before writing the code and the experience was broadly positive. I've been trying, whenever possible, to write tests along side new code i write. Warren Hill on How to create forms at run tim…
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |