primerib1 Posted January 21 Share Posted January 21 (edited) As the title asks: How to do Test-Driven Development w.r.t. LSL Scripting. Likely will use a combination of external tools. And need a 'pipeline' to work, a 'toolchain' so to speak. So feel free to share / discuss. Edited January 21 by primerib1 Link to comment Share on other sites More sharing options...
animats Posted January 21 Share Posted January 21 What do you want to test? LSL programs are not that interesting in isolation. They have to interact with the world to be useful. That said, on one occasion I really did need a serious test tool. I wrote a maze solver for my NPCs. I had to do that by developing it in Python, debugging it there using a random maze generator, and then translating the result to LSL. 1 Link to comment Share on other sites More sharing options...
primerib1 Posted January 21 Author Share Posted January 21 (edited) 38 minutes ago, animats said: LSL programs are not that interesting in isolation. They have to interact with the world to be useful. And that's exactly what I want to test. Like: Test if a toucher is blacklisted => should return an error message to the toucher Test if a toucher's active group is blacklisted => should return an error message to the toucher Test if a toucher is not blacklisted but no items to give from inventory => should return an information message Test if a toucher is not blacklisted and there are items to give => should receive the items Things like that. So that in the future as I add features / fix bugs / introduce optimizations, the externally-visible behavior of the script stays the same. Edited January 21 by primerib1 Link to comment Share on other sites More sharing options...
Wulfie Reanimator Posted January 21 Share Posted January 21 (edited) We don't have any kind of testing framework to work with, so test-driven development for LSL is impossible (or super impractical). We can't trigger events (especially touch) or observe most behavior externally. The only way you could test anything is to have the tests in the same script as the implementation, which eats at your bytecode and active memory a lot. Instead of having a listen event with LSL code in it, you would only have a bunch of user-function calls in the listen event. And for each user-function, you would also write multiple user-functions to test every aspect of that function. 6 hours ago, primerib1 said: So that in the future as I add features / fix bugs / introduce optimizations, the externally-visible behavior of the script stays the same. This is a very limited way of testing things and not worth the effort IMO. Edited January 21 by Wulfie Reanimator 1 Link to comment Share on other sites More sharing options...
Recommended Posts
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now