It depends.
Some infrastructure (like [Singleton], which is used by Timer) need a storage account since they use blob leases for coordination. Logging can be disabled.
On one extreme, if you're binding to cloud resources (ie, DocDb) or using cloud-based triggers, then clearly you must be online.
Some bindings (like blob) can work against a storage emulator, but this a case-by-case basis.
On the other extreme, Azure Functions parameter binding makes it very mock-friendly which would let you invoke your functions directly offline (and also in unit tests) rather than go through the Azure Functions listening + dispatch logic. For example, you can bind a Blob to a Stream or TextReader, and then directly invoke your function and pass them streams that are bound to in-memory or file system. The IAsyncCollector interfaces are also very mock friendly.
Our own unit tests in the WebJobs SDK heavily leverage this (see https://github.com/Azure/azure-webjobs-sdk/blob/b8674651654f27a51ffadd0d38b4f89ce246b7a1/test/Microsoft.Azure.WebJobs.Host.UnitTests/Indexers/ReturnValueTests.cs as an example)