How can I run a non-main package?

<p>I&#39;m new to Go. I&#39;m creating a package that might be reusable for one of my projects, but without a &#34;main&#34; package I&#39;m not sure how I can run it to test it while developing it. I can import it into my main project, but that seems very cumbersome (every change I need to rebuild package, rebuild project, and run).</p> <p>Is there an easier way? Should I try to do this just via &#34;go test&#34;?</p> <hr/>**评论：**<br/><br/>natefinch: <pre><p>So, I assume by your hesitation that you&#39;re not looking to write formal tests just yet, but that you simply want your code to run so you can ensure that it does what you expect. </p> <p>Go test can be used for that, too. I often use a test as an entrypoint to my code to exercise it and figure out what it&#39;s doing. Just slap a <code>func TestStuff(t *testing.T) { }</code> in a foo_test.go file, and put the &#34;main&#34; code inside the test to run your code. Then running <code>go test</code> in the library directory will run that test function (if you have other tests in the same file, you can tell it to only run that one function with <code>go test -test.run=TestStuff</code>).</p> <p>That&#39;s probably the simplest way, and then you have a test file all set up for when you write actual tests :)</p></pre>mf192: <pre><p>For testing ideas and basic functionality you can use <a href="https://play.golang.org" rel="nofollow">https://play.golang.org</a></p> <p>Outside of this Go makes a distinction between executables (main) and libraries. </p> <p>You’d typically start with main, and if you have a clear need to separate parts of the code move it to a package. Then call that package from main. Make sure to use Upper case for exportable items.</p> <p>Usually when prototyping you’d just ‘go run main.go’ , this temporarily builds an executable and runs it. Most users have linting, fmt, etc built into their editors so it updates every time code is saved.</p></pre>faiface: <pre><p>You don&#39;t need to rebuild package and project manually every time. If you just build the project (or even <code>go run</code> it) it will rebuild everything automatically.</p></pre>jerf: <pre><blockquote> <p>every change I need to rebuild package, rebuild project, and run</p> </blockquote> <p>First, I agree with natefinch&#39;s post. This is not a Go suggestion, but a general shell expertise suggestion. Rebuilding and then running should not be something you find yourself reluctant to do. You should find some way to make that easy for you, because the time spent doing that will pay off in a lot of ways.</p> <p>I don&#39;t know your environment, but one of the simplest ways to do it in Linux (and I <em>think</em> even the simplest command shell in Windows) is to type out the build commands once, and then just use &#34;up arrow, enter&#34; to re-run again. If you use incremental building, I find it&#39;s almost always as fast as a scripting language (and as the project grows, actually faster). Exactly what you need depends on what you have, but something as simple as</p> <pre><code>go build -i -v &amp;&amp; ./my_program </code></pre> <p>is a good start. <code>-i</code> means incremental build, so unchanged packages are not recompiled. -v is just because I like to see the compile go by; YMMV. (When I do make a change deep in the dependency hierarchy, seeing all the other packages go by keeps me from wondering what&#39;s taking 2 seconds.) You can start elaborating on this easily; you may want to feed a specific package path to go build if you&#39;re not in the directory where the executable is (I often work from the top level directory of my project, which may not even be a &#34;go&#34; directory), you can put a <code>go test &amp;&amp;</code> to validate test code before even running the core exe, you can feed the test command itself other things.... you can tune it as you go.</p> <p>You can also create a little script to do whatever, but I find that the command line history is generally enough. (Usually anything <em>really</em> fancy I want to do, I do on the commit prehook. For instance, when I&#39;m just running some code to see if I did something I actively <em>don&#39;t</em> want the lint checks running yet.)</p></pre>Delta9Tango: <pre><p>Makefile might be good for this.</p> <p>I am by far not a Makefile expert, but it is an excellent way to make sure that repeated tasks are scripted. </p></pre>brokenprogram: <pre><p>Just use <code>go test</code>. See <a href="https://golang.org/pkg/testing/" rel="nofollow">https://golang.org/pkg/testing/</a> </p></pre>Morgahl: <pre><p>If you really want a library to have its own main for other purposes then testing you can always do a <code>libname/internal/cmd/libname</code> folder that has a <code>main</code> that string things together. We tend to do this extensively where I work as we have microservices built around a library of their own functionality with the actual service <code>main</code> buried. This lends us a good amount of code reuse across communicating services, without reimplementing.</p></pre>rohit2929: <pre><p>You can call your &#34;main&#34; or &#34;entry&#34; function from init() function as they run without main also </p></pre>natefinch: <pre><p>yeah, but you still need some kind of main function to run to get the init code to run.</p></pre>