Date
1 - 7 of 7
Compiling unit test code along with main target?
Rick Mann
I tend to neglect my unit tests for long stretches, and pay the price. One thing that would help would be if I had to deal with compiler errors each time I made a change to the main target. Is there any way to get Xcode to build all the unit tests (but not run them) each time I hit Command-B on my main target?
Oh, and this is actually a SwiftPM project. Thanks, -- Rick Mann rmann@latencyzero.com
|
|
Yup.
—Jens
|
|
Alex Zavatone
I think it builds based on the scheme.
toggle quoted messageShow quoted text
I wonder if you could do a complex build scheme. Or write a script to do the build through the terminal and using behaviours wire up a key to execute that script to execute multiple build targets. This sounds like something you can do with xcodebuild. I’m sure I’m overlooking something here. Need coffee. From what I remember, you can do this with VSTS, but the configs are in cursed YAML. Even with Jenkins and Xcode Server, you can fire off builds on a checkin. Alex Zavatone.
On Sep 14, 2020, at 1:25 AM, Rick Mann <rmann@latencyzero.com> wrote:
|
|
Alex Zavatone
Xcodebuild supports multiple targets.
toggle quoted messageShow quoted text
|
|
On 13 Sep 2020, at 11:25 pm, Rick Mann <rmann@latencyzero.com> wrote:Jens has answered your question. But to ask a different one: what meaningful good does building your tests -- but not running them -- actually do? I'd argue that a test not run is as good as a test not written. Just run the tests once in awhile. Cmd-U is as easy as Cmd-R. I've developed a habit of doing both, especially prior to committing any code. (Well, at least when I've been working on projects that HAVE test suites 🙃) -ben
|
|
Alex Zavatone
Ben, I think that he should set up a trigger and spool up an Xcode server, if only for this type of operation. On checkin, or push to the remote, build and run the app and test target(s) and send the report through email to himself once a day through email.
toggle quoted messageShow quoted text
For me, I don’t want a result every time I make a checkin. It’s part of the workflow. I want to come in the next day after my head is clear, review the results of the tests and address any open issues with a clean head. The only pain is if you haven’t set it up as part of your workflow to merge into a build and review branch, then run the tests and fix any open issues. I suggest this, because you can have an Xcode Server (or Jenkins or whichever CI you use) to only perform builds, runs, and target tests on actions performed on a specific branch. When you’ve done the work, fine tuned all the code, the idea is that then, you merge into a review and test branch where these tests and operations are done before the review and resulting merge into your master or working master branch.
|
|
Rick Mann
Thanks, Jens. That was exactly the right answer, and now I feel like an idiot because they were already selected. I could swear it wasn't building the tests, but I guess I was wrong.
toggle quoted messageShow quoted text
On Sep 14, 2020, at 09:35 , Jens Alfke <jens@mooseyard.com> wrote:On Sep 13, 2020, at 11:25 PM, Rick Mann <rmann@latencyzero.com> wrote:Yup. --
Rick Mann rmann@latencyzero.com
|
|