A Week of Little Improvements
This was one of those weeks where I didn't make a ton of progress in any one area, except to tie up a bunch of loose ends that were hanging around:
-
I finally incorporated Dennis' method to unwrap keyed parameters from Method Invocations into a usable format (one of the things Michelle needed access to for her study tests)
-
For the InvokedAPI I wrote last week, I was concerned that, due to it being the first non-static API class, that repeatedly constructing it and destroying it in the isValidConstruct code that users write might be costly and inefficient. To combat this, I made a class called "NonStaticAPI" that is a member of the Python test class. This is only created once, and so the user just uses self.API whenever they need access to non-static API classes (currently just InvokedAPI, but doing it in this format allows for more non-static API classes to easily be added in the future).
- Although last week during my demo, InvokedAPI was working properly, it made use of some deprecated methods and relied on the IDE, which is unavailable on the server. While talking with Kyle this week, we came up with a way around this by passing in the "main" method (which is already available when code tests get created) and finding initializeEventListeners from out of main. This required some reworking of a bunch of classes relying on the InvokedAPI, but it now seems to be working.
-
There were several bugs hanging around in the ExpressionStatementChunkCrawler that I hadn't noticed, but proved to be fairly straightforward fixes. In the process, I realized that the ChunkCrawler really should make use of the InvokedAPI as well (with the "Only invoked code?" option), so I added that back in as well.
-
Reilly discovered that the ConstructCrawler had left out Conditional statements as an option. I added this in, and figured that it was probably a good idea to add this to the Extended Return options as well (if someone was looking for a certain pattern contained in an If/Else block). While adding this in, I uncovered some other bugs that had worked their way into extended return types when the crawler options had been factored out, and corrected those as well.
On one hand, it's definitely a good thing that I made all these improvements this week. On the other, it ended up distracting me from what Kyle and I decided needs to be the next step before code tests should be updated to run on the server: a more robust set of Unit Tests needs to be developed for Code Tests. I've gotten the current set of existing Unit Tests running again, but have not managed to develop any more. With any luck, before our meeting on Friday, I will have time to brainstorm what additional tests will be helpful, and implement, or start implementing them.
Comments
Log In or Sign Up to leave a comment.