@Michael Davidovich we'd generally set ^UnitTestRoot to the path in the cloned repo and then run tests right from there. Another workflow might be to have unit tests run in their own namespace that has all the same code/supporting data but is distinct from the namespace where you're doing dev work - in that case, it's safe to delete the unit tests from that second namespace. (But practically speaking we just use one namespace and don't delete.)
Re: best practices/shortcuts as an individual developer, I'd honestly just say embrace the automation and iterate in a feature branch with the tests running on commit to feature branches (not just main). It also helps to use the package manager to make a more modular codebase where each module has its own associated tests, so you're not rebuilding and testing everything every time.
In a case where you're (a) using the package manager and (b) being really strict about test coverage, combining the techniques in the article I linked earlier is a good approach - e.g., saying to run specific tests *and* measure test coverage. That helps answer "how well do the tests I'm currently writing cover the code I'm currently adding/changing?"
Of course, you can do this with the normal APIs for running unit tests with test coverage too. (TestCoverage.Manager also has DebugRunTestCase - think of it like %UnitTest.Manager but with test coverage built in.)
WARNING! When you implement this (using %CSP.StreamServer or whatever), make sure that you're not opening up a way for a malicious user to download any arbitrary file on the server.
set req = ##class(%Net.HttpRequest).%New()
set req.SSLConfiguration="MBTA"// Set this up in the management portal under Security Management > SSL/TSL Configurations; this is the SSLConfig's "Name"// For HTTP Basic authentication, simple route is e.g.:set req.Username = "foo"set req.Password = "bar"// For other modes, e.g.:do req.SetHeader("Authorization","Bearer abcd")
set sc = req.Get("https://api-v3.mbta.com/routes")
// TODO: check sc / $$$ThrowOnError(sc)// TODO: check req.HttpResponse.StatusCode to make sure it's 200 and error handle appropriatelyset obj = {}.%FromJSON(req.HttpResponse.Data)
zw obj // There's your object!
@Vitaliy.Serdtsev thank you for pointing there! I couldn't find that via the new-and-improved (but still in progress) doc search and have provided feedback to that effect.
Side note: I love having the "Feedback" button on the right side in the docs, and it's great to see the amazing effort being put in to improving the docs, search, etc.
go to post
@Michael Davidovich we'd generally set ^UnitTestRoot to the path in the cloned repo and then run tests right from there. Another workflow might be to have unit tests run in their own namespace that has all the same code/supporting data but is distinct from the namespace where you're doing dev work - in that case, it's safe to delete the unit tests from that second namespace. (But practically speaking we just use one namespace and don't delete.)
Re: best practices/shortcuts as an individual developer, I'd honestly just say embrace the automation and iterate in a feature branch with the tests running on commit to feature branches (not just main). It also helps to use the package manager to make a more modular codebase where each module has its own associated tests, so you're not rebuilding and testing everything every time.
In a case where you're (a) using the package manager and (b) being really strict about test coverage, combining the techniques in the article I linked earlier is a good approach - e.g., saying to run specific tests *and* measure test coverage. That helps answer "how well do the tests I'm currently writing cover the code I'm currently adding/changing?"
Of course, you can do this with the normal APIs for running unit tests with test coverage too. (TestCoverage.Manager also has DebugRunTestCase - think of it like %UnitTest.Manager but with test coverage built in.)
go to post
@Michael Davidovich - @Pravin Barton is from my team, so I have little to add to what he said - other than to also point to https://community.intersystems.com/post/unit-tests-and-test-coverage-obj.... If you're using InterSystems' package manager it makes tests much easier/more natural to run.
go to post
WARNING! When you implement this (using %CSP.StreamServer or whatever), make sure that you're not opening up a way for a malicious user to download any arbitrary file on the server.
go to post
@Vitaliy Serdtsev thank you for pointing this out. We've fixed the issue; it was actually a separate root cause from before.
go to post
This is a bug. We'll look into it. Thank you for bringing it to our attention.
go to post
Not a full answer, but OnDrawCell is the place to start: https://docs.intersystems.com/ens201815/csp/docbook/DocBook.UI.Page.cls?...
go to post
Sure, here's one:
set req = ##class(%Net.HttpRequest).%New() set req.SSLConfiguration="MBTA" // Set this up in the management portal under Security Management > SSL/TSL Configurations; this is the SSLConfig's "Name" // For HTTP Basic authentication, simple route is e.g.: set req.Username = "foo" set req.Password = "bar" // For other modes, e.g.: do req.SetHeader("Authorization","Bearer abcd") set sc = req.Get("https://api-v3.mbta.com/routes") // TODO: check sc / $$$ThrowOnError(sc) // TODO: check req.HttpResponse.StatusCode to make sure it's 200 and error handle appropriately set obj = {}.%FromJSON(req.HttpResponse.Data) zw obj // There's your object!go to post
Turns out the problem was *not* the woff files at all - it was the CSS file that used the font. Solution was:
set ^%SYS("CSP","MimeFileClassify","CSS")=$lb("text/css",0,"utf-8")go to post
Update: it looks like we now support local edit/save/compile of CSP application files, provided the web application name starts with "/csp" - see: https://github.com/intersystems-community/vscode-objectscript/pull/622
go to post
@Vitaliy.Serdtsev thank you for pointing there! I couldn't find that via the new-and-improved (but still in progress) doc search and have provided feedback to that effect.
Side note: I love having the "Feedback" button on the right side in the docs, and it's great to see the amazing effort being put in to improving the docs, search, etc.