https://community.wolfram.com RSS Feed for Wolfram Community showing any discussions tagged with Software Development sorted by new. https://community.wolfram.com/groups/-/m/t/3754125 ![Circadian-based optimization of personalized sleep schedules][1] &[Wolfram Notebook][2] [1]: https://community.wolfram.com//c/portal/getImageAttachment?filename=Screenshot2026-07-09at7.30.59%E2%80%AFPM.png&userId=3753710 [2]: https://www.wolframcloud.com/obj/3669d397-cad8-4514-a1a4-b75db3a2d62e Warren Chen 2026-07-10T00:58:00Z https://community.wolfram.com/groups/-/m/t/3746334 &[Wolfram Notebook][1] [1]: https://www.wolframcloud.com/obj/43a7232a-c3cf-4944-9d00-9033b68cb918 Dara Shayda 2026-07-07T01:30:21Z https://community.wolfram.com/groups/-/m/t/3741886 While working on internal projects, I often found that want to add extra functionality on top of the existing functions of `TestReport` and `TestCreate`, `TestEvaluate` etc. Recently I made an effort to compile all of these custom functionalities into my own package and publish it for general use on [my own Github account here](https://github.com/SjoerdSmitWolfram/UnitTestFramework). I have tried to make the Github repo reasonably self-explanatory, but I would like to post some of the headline functionality here for everyone's benefit. The main code is found in [UnitTestFramework.wl](https://github.com/SjoerdSmitWolfram/UnitTestFramework/blob/main/UnitTestFramework/Kernel/UnitTestFramework.wl), which I deliberately kept as a single file so that it's easy to load remotely using ``` Get["https://raw.githubusercontent.com/SjoerdSmitWolfram/UnitTestFramework/refs/heads/main/UnitTestFramework/Kernel/UnitTestFramework.wl"] ``` Of course, you can also install the paclet and load it locally. The repository has an [example paclet with a small test suite](https://github.com/SjoerdSmitWolfram/UnitTestFramework/tree/main/Examples) to show broadly how things are expected to be structured. The example paclet also has a WolframScript file that gives can be used and adapted to run your unit tests from the command line so you can easily run them without interrupting your main workflow. # What is UnitTestFramework and why should you use it? UnitTestFramework is a reusable test runner for paclet-style Wolfram Language projects. It is built around the standard MUnit workflow, but adds a more practical layer on top for people who need to run larger or more structured test suites. The main idea is simple: keep using familiar test constructs such as `TestCreate`, but gain better control over how tests are discovered, configured, tagged, skipped, summarized, and run from automation. This matters because once a test suite grows beyond a handful of files, you usually want more than a raw TestReport. You want a way to separate quick local runs from full runs, mark known failures without losing visibility, skip auto-generated or expensive tests when appropriate, and get a summary that is actually useful in CI (continuous integration) and day-to-day development. # Main functionalities ## Configuration of test suites One of the main features of the framework is that test runs are driven by a project-level configuration file such as [TestConfig.m](https://github.com/SjoerdSmitWolfram/UnitTestFramework/blob/main/Examples/Tests/TestConfig.m) (though other formats like .json are also supported to some extent). Instead of hard-coding behavior into ad hoc scripts, you can define things such as: * where test files live * which test files to include * which paclet contexts should be loaded * whether to abort on the first unexpected failure (so you can easily reproduce the kernel state at the point of failure) * whether to run a full test suite or a quicker local version * custom initialization and evaluation behavior and fine control over which contexts are visible while tests are running. * isolation of the contents of each test file (so that variables defined in one test file do not affect tests in another file) * local machine-specific overrides through an optional LocalConfig file * configuration of local dependencies, such as other paclets that you're developing in unison with the one you're currently testing If you're using the .m format for the TestConfig file, you can also extend the unit test framework with your own code, such as helper functions for deciding how to handle numerical noise in outputs. The test configuration file makes the test runner much easier to reuse across projects because it factors out all of the project-specific peculiarities into a file that's easy to commit and maintain. The same framework can be loaded once and then adapted per paclet by changing the config, rather than rewriting the test infrastructure every time. You can even have multiple test files to configure different ways to run the tests. Most projects will require minimal setup to get the test suite up and running; the main property to configure will be the `"PacletContexts"`. Other properties only need to be tinkered with if the project is structured differently from the default assumptions. ## Tagging tests A second major feature is test tagging through `TagTest`. This lets you attach metadata to tests in a structured way and then use that metadata to control execution and reporting. For example, you can mark tests as: * known issues * not yet implemented * performance tests * generated tests * full-report-only tests * to-be-skipped That turns out to be extremely useful in practice. Real test suites are not always just pass or fail. Sometimes a failure is expected because a bug is known. Sometimes a test is intentionally present before the implementation exists (i.e., test-driven development). Sometimes a test is too expensive for every local run. Tags make those cases explicit instead of forcing them into awkward workarounds. ![Examples of tagged tests][1] ## Test summaries The framework also adds categorized summaries on top of the raw test results. Instead of only seeing whether a run passed or failed, you can group results into categories such as Success, Failure, KnownIssue, NotImplemented, PerformanceFailure, Fixed, Implemented, and Skipped. This gives a much better high-level view of the state of a test suite and helps answer questions like: * Which files are producing real failures? * Which failures are already known? * Which not-yet-implemented tests have started passing? * Which tests were skipped in a local run? For CI, the framework also builds a filtered report focused on the categories that should actually affect pass/fail decisions, while still keeping the richer result structure available for analysis. ![A typical test summary][2] ## Command line interface The repository also includes example scripts for running tests from the command line, which makes the framework suitable for automation and CI workflows. That means you can use the same test infrastructure both interactively inside the Wolfram Language and non-interactively from scripts. If you maintain paclets or other structured projects, this makes it much easier to integrate testing into build pipelines, local shell workflows, and repeatable project setup. The example unit tests can be run from the command line (assuming you start it in the root directory of the repository) with the following line: ``` wolframscript -file Examples/Tests/run_tests.wls ``` ![Running the unit tests from the command line][3] The overall goal is to make Wolfram Language testing feel less like a one-off notebook activity and more like a maintainable development workflow. If you have any questions or suggestions, please let me know! [1]: https://community.wolfram.com//c/portal/getImageAttachment?filename=Taggingtests.png&userId=839741 [2]: https://community.wolfram.com//c/portal/getImageAttachment?filename=Testsummary.png&userId=839741 [3]: https://community.wolfram.com//c/portal/getImageAttachment?filename=commandline.png&userId=839741 Sjoerd Smit 2026-06-30T14:16:27Z https://community.wolfram.com/groups/-/m/t/3740183 I am developing Extending Fraction Frontiers, an interactive Mathematica / Wolfram Language environment for teaching fractions, ratios, common units, and rational-number reasoning. The project is currently a working prototype in a dynamic notebook. I am looking for a freelance Wolfram Language developer who can help stabilize, refactor, and extend the code. Extending Fraction Frontiers is designed to help students explore fractions and ratios through coordinated visual representations of magnitudes, units, lattice points, and number-line locations. The current prototype uses several linked panes, including target magnitudes, an integer lattice, a number line, dashboard controls, and conjecture-testing displays. The goal is to support students in reasoning about fractions as expressions of relative magnitude, common units, and equivalent ratios, rather than treating fractions only as part-whole symbols. The code currently involves substantial use of: • DynamicModule • Manipulate • Graphics • Grid • Pane • LocatorPane • state management across coordinated displays • layout control for multiple interactive panes • possibly packaging code into .wl files I am especially interested in someone with experience in interactive Mathematica notebooks, clean Wolfram Language programming, mathematical or educational visualization, and readable code documentation. The initial task would be a paid diagnostic review of the current notebook, followed by: • a proposed refactoring plan, and • one representative code improvement. Alternatively, the first task could focus on two concrete prototype improvements: • implementing a dropdown menu that determines which panes are available in different modes or stages of use, and • ensuring that the active panes are displayed at appropriate sizes and positions depending on which combination of panes is currently shown. If the collaboration works well, I would like help completing the software prototype. I can share additional details privately after an initial exchange. Please respond with examples of prior Wolfram Language work, especially interactive notebooks, visualizations, packages, or educational tools. It would also be helpful to include your availability and hourly rate. David Carraher 2026-06-29T00:26:03Z https://community.wolfram.com/groups/-/m/t/3720941 &[Wolfram Notebook][1] [1]: https://www.wolframcloud.com/obj/346760a8-fe52-47a7-b452-f945a4ca1986 Brian A. Mboya 2026-05-22T18:35:43Z https://community.wolfram.com/groups/-/m/t/3720182 ![enter image description here][1] &[Wolfram Notebook][2] [1]: https://community.wolfram.com//c/portal/getImageAttachment?filename=3470hero.png&userId=20103 [2]: https://www.wolframcloud.com/obj/7d116d6f-a55a-4d07-9873-c9201303db83 Anton Antonov 2026-05-21T22:16:16Z https://community.wolfram.com/groups/-/m/t/3716255 &[Wolfram Notebook][1] [1]: https://www.wolframcloud.com/obj/8cb6693a-dd97-4ab3-b753-6f0bbc77d18c Arnoud Buzing 2026-05-14T16:59:43Z https://community.wolfram.com/groups/-/m/t/3711368 &[Wolfram Notebook][1] [1]: https://www.wolframcloud.com/obj/5c8debc6-a7fd-4b2d-a23b-37a07d81fe5c Jayanta Phadikar 2026-05-04T16:02:13Z https://community.wolfram.com/groups/-/m/t/3680195 ![Job Opportunity with Emerald Cloud Lab!][1] **Emerald Cloud Lab (ECL)** is the world's leading remote research laboratory, allowing scientists to run experiments 24/7/365, from anywhere in the world. The entire lab is run on a build out of Wolfram Language - Symbolic Lab Language, which standardizes how biological and chemical laboratory experiments and their resulting data are designed, executed, and analyzed. Scientific methods are translated into code, then executed in our state-of-the art laboratory. The full documentation and all current running experiments can be seen here: https://www.emeraldcloudlab.com/documentation/ Winner of the Wolfram Innovator award https://www.wolframconsulting.com/powering-a-life-science-lab-in-the-cloud/ ECL is becoming a powerful platform for the future of the biotech industry. **We are hiring!** For current job openings see below and contact careers@emeraldcloudlab.com **Interested?** Join us for a live interactive tele-tour with Co-Founder and CEO, Brian Frezza. The session will include an overview of ECL's history and aims as well as a deep dive into our technology. It is intended to give you a genuine sense of how ECL works and how our various teams come together to make what we do possible. For information on upcoming sessions and to sign up, please contact: careers@emeraldcloudlab.com **Backend Engineer** - We are seeking a Senior Backend Software Engineer to join our backend team and help build the services that power the future of scientific research. You will develop and maintain critical APIs and services that enable scientists to orchestrate complex experiments remotely. This role offers the unique opportunity to solve challenging problems at the intersection of cloud computing, laboratory automation, and scientific instrumentation. **Front End Engineer** - We are seeking a Senior Front End Software Engineer to join our front end team and help build the UI that power the future of scientific research. You will develop and maintain code and services that enable scientists to orchestrate complex experiments remotely. This role offers the unique opportunity to solve challenging problems at the intersection of cloud computing, laboratory automation, and scientific instrumentation. **Scientific Developer** - We are an automated cloud-based laboratory. The role is pivotal in ensuring seamless transition for customers as they onboard on the ECL platform, optimizing experimental workflows for reproducibility, ease of use, and high-quality data output. As a customer-facing liaison and the bridge between our customers and platform, you will work closely with customers and internal teams to translate research needs into executable experiments, oversee their successful implementation, and troubleshoot >**Website:** https://www.emeraldcloudlab.com >**LinkedIn:** https://www.linkedin.com/company/emerald-cloud-lab [1]: https://community.wolfram.com//c/portal/getImageAttachment?filename=Screenshot2026-04-03073618.png&userId=3680157 Sophia Wolfram 2026-04-09T17:11:20Z https://community.wolfram.com/groups/-/m/t/3659892 &[Wolfram Notebook][1] [1]: https://www.wolframcloud.com/obj/fab0aaa2-5d63-4566-8eca-4240f66f7920 Daniel Carvalho 2026-03-14T01:14:56Z https://community.wolfram.com/groups/-/m/t/3656544 [![Black Hole Vision: an interactive iOS application for visualizing black holes][1]][2] &[Wolfram Notebook][3] [1]: https://community.wolfram.com//c/portal/getImageAttachment?filename=BlackHoleVision-aninteractiveiOSapplicationforvisualizingblackholes.jpg&userId=20103 [2]: https://community.wolfram.com//c/portal/getImageAttachment?filename=BlackHoleVision-aninteractiveiOSapplicationforvisualizingblackholes.jpg&userId=20103 [3]: https://www.wolframcloud.com/obj/c94b0ce3-acb0-4f23-adb6-e8aa2d4158f3 Alex Lupsasca 2026-03-10T20:30:37Z https://community.wolfram.com/groups/-/m/t/3646989 ![Salvo Combat Modeling: Battle of Coronel][1] &[Wolfram Notebook][2] [1]: https://community.wolfram.com//c/portal/getImageAttachment?filename=SalvocombatmodelingBattleofCoronel.png&userId=20103 [2]: https://www.wolframcloud.com/obj/3a7678cb-0540-4a1d-85d8-793ac90dbe65 Anton Antonov 2026-03-01T18:18:51Z https://community.wolfram.com/groups/-/m/t/3644501 &[Wolfram Notebook][1] [1]: https://www.wolframcloud.com/obj/00f106b5-05e6-4f07-a413-7aa01bfda03c Furkan Semih Dündar 2026-02-24T10:38:11Z https://community.wolfram.com/groups/-/m/t/3642399 Against the backdrop of such rapid development of AI, will the functions of mathematical software like Mathematica be completely replaced or partially replaced by AI in the future? Why? Bill Blair 2026-02-20T13:26:23Z https://community.wolfram.com/groups/-/m/t/3638644 ![Computational Generation of Constructed Languages][1] &[Wolfram Notebook][2] [1]: https://community.wolfram.com//c/portal/getImageAttachment?filename=Screenshot2026-02-11at9.53.45%E2%80%AFAM.png&userId=911151 [2]: https://www.wolframcloud.com/obj/fb0f723d-663b-476d-a693-2ad8f25f34ec Wolfram Education Programs 2026-02-11T16:35:39Z https://community.wolfram.com/groups/-/m/t/3623800 &[Wolfram Notebook][1] [1]: https://www.wolframcloud.com/obj/9748b87a-8a46-4a41-8ff7-63d03a77ad23 Naman Taggar 2026-01-24T08:40:01Z https://community.wolfram.com/groups/-/m/t/3592839 ![The CLICK protocol: solving AoC's secret entrance with a Turing machine][1] &[Wolfram Notebook][2] [1]: https://community.wolfram.com//c/portal/getImageAttachment?filename=CLICKprotocol2.png&userId=20103 [2]: https://www.wolframcloud.com/obj/2fd6cbe1-5985-4885-bd11-08577bbac7ee Brian A. Mboya 2025-12-17T12:36:17Z https://community.wolfram.com/groups/-/m/t/3585514 ![Monads natural transformations: categories for the working programmers][1] &[Wolfram Notebook][2] [1]: https://community.wolfram.com//c/portal/getImageAttachment?filename=9112Monadsnaturaltransformationscategoriesfortheworkingprogrammers.png&userId=20103 [2]: https://www.wolframcloud.com/obj/02fbc58e-0761-4081-b3dc-d9883d7ad05a Dara Shayda 2025-12-04T15:07:02Z https://community.wolfram.com/groups/-/m/t/3574036 Hello! I find myself wanting to write functions that do a common WL thing: produce as their output an 'object' function which is then queried by sending arguments. The statistical fitting functions are an example: you get a 'fitted model' object from which you extract different outputs, e.g.,: myFit["ParameterTable"] myFit["AIC"] But I can't seem to find any examples of how these 'object functions' are coded within the functions that produce them. I can think of some ways it *could* be done, but I'm guessing there is a standard way that WL functions do it, and I would prefer to just copy that. Does anyone know? Is there a template? Gareth Russell 2025-11-12T23:46:44Z https://community.wolfram.com/groups/-/m/t/3551033 ![An application for portfolio optimization, risk sensitivity and efficient frontier visualization in Mathematica][1] &[Wolfram Notebook][2] [1]: https://community.wolfram.com//c/portal/getImageAttachment?filename=Anapplicationforportfoliooptimization,risksensitivity.png&userId=20103 [2]: https://www.wolframcloud.com/obj/7963e970-e9ea-4c03-860d-cdf93ae98de7 Charalampos-Marios Pelekoudas 2025-09-25T18:03:12Z